http://www.xenproject.org/security-policy.html
----------
Public hosting providers;
Large-scale organisational users of Xen;
Vendors of Xen-based systems;
Distributors of operating systems with Xen support.
Here "provider", "vendor", and "distributor" is meant to include anyone who is making a genuine service, available to the public, whether for a fee or gratis. For projects providing a service for a fee, the rule of thumb of "genuine" is that you are offering services which people are purchasing. For gratis projects, the rule of thumb for "genuine" is measured in terms of the amount of time committed to providing the service. For instance, a software project which has 2-3 active developers, each of whom spend 3-4 hours per week doing development, is very likely to be accepted; whereas a project with a single developer who spends a few hours a month will most likey be rejected.
----------
Basically, if you provide a service to the public which uses Xen (Not restricted on size), or use Xen at large scale internally, you can get on the list. There are several small hosting providers that utilize Xen on that list.
Presumably if you use Xen at small scale internally you're less worried about security vulnerabilities as it is only your employees with root access to the machines - if external users have root access, you probably fall under one of the other definitions.
On the Rackspace public cloud I've been through three full-fleet reboot cycles so far. Only one of those affected AWS customers, and AWS handled it in such a way that only a portion of their fleet was affected.
How could AWS do this when Rackspace and others couldn't?
For one, they could stratify guest placement based on instance type and guest OS. (Which I hear they do.) Most recent XSAs have only affected PV or HVM guests, not both. If you keep PV and HVM guests separate ...
AWS seems to be an example of good engineering, not an example of the perils of capitalism.
Maybe next you'll insist that everyone's prevented from patching for a week after disclosure so that smaller companies that don't have the resources to react immediately are not unfairly left behind?
It is fundamentally unfair, and sets up a non-level playing field.
(inb4 "critical infrastructure")
It is fundamentally unfair, and is perfectly reasonable.
Profit and PR are hardly the goal here -- community awareness and public safety are paramount. Vulnerabilities need to be obviated to the general populace at large.
This is the endgame of your so-called "responsible disclosure". Those with profit loss exposure win, and the peasants get it whenever the PR company is done making the logo and infographics.