Re: [Xen-devel] HVMlite ABI specification DRAFT A

[Tim Deegan <tim@xxxxxxx>]

At 17:14 +0000 on 05 Feb (1454692488), Andrew Cooper wrote:
> On 05/02/16 16:01, Tim Deegan wrote:
> > At 18:48 +0100 on 04 Feb (1454611694), Roger Pau Monné wrote:
> >> Hello,
> >>
> >> I've Cced a bunch of people who have expressed interest in the HVMlite
> >> design/implementation, both from a Xen or OS point of view. If you
> >> would like to be removed, please say so and I will remove you in
> >> further iterations. The same applies if you want to be added to the Cc.
> >>
> >> This is an initial draft on the HVMlite design and implementation. I've
> >> mixed certain aspects of the design with the implementation, because I
> >> think we are quite tied by the implementation possibilities in certain
> >> aspects, so not speaking about it would make the document incomplete. I
> >> might be wrong on that, so feel free to comment otherwise if you would
> >> prefer a different approach. At least this should get the conversation
> >> started into a couple of pending items regarding HVMlite. I don't want
> >> to spoil the fun, but IMHO they are:
> >>
> >>  - Local APIC: should we _always_ provide a local APIC to HVMlite
> >>    guests?
> >>  - HVMlite hardware domain: can we get rid of the PHYSDEV ops and PIRQ
> >>    event channels?
> >>  - HVMlite PCI-passthrough: can we get rid of pciback/pcifront?
> > FWIW, I think we should err on the side of _not_ emulating hardware or
> > providing ACPI; if the hypervisor interfaces are insufficient/unpleasant
> > we should make them better.
> >
> > I understand that PCI passthrough is difficult because the hardware
> > design is so awkward to retrofit isolation onto.  But I'm very
> > uncomfortable with the idea of faking out things like PCI root
> > complexes inside the hypervisor -- as a way of getting rid of qemu
> > it's laughable.
> 
> Most certainly not.
> 
> 90% of the necessary PCI infrastructure is already in the hypervisor,
> and actively used for tracking interrupt mask bits.  Some of this was
> even introduced in XSAs, and isn't going away.

This is the chance to _make_ it go away.  If we commit to modelling
IO-APICs and PCI bridges now, we'll be stuck with it for a while.

I'm not suggesting that we have to stick with pcifront, and I
appreciate the argument that at some point Xen must control the PCI
devices, but it doesn't follow that emulated hardware is the ABI Xen
should expose for that.

> Yes, this does involve adding a little extra emulation to Xen, but the
> benefits are a substantially cleaner architecture for device models,
> which doesn't require them to self-coordinate about their layout, or
> have to talk to Qemu directly to negotiate hotplug notifications.

Now that's a different thing altogether -- emulated device models
presenting as PCI devices.  And here I still disagree with you -- Xen
shouldn't have to decide device models' layouts.  That's _policy_, and
the hypervisor's job is _enforcement_.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel