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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 5/2/16 a les 17:01, Tim Deegan ha escrit:
> 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.

Well that's one of the side of it. It's not really that they are
insufficient/unpleasant (or not properly documented) it's just that they
require substantial work to implement and maintain in guest OSes. So we
have the burden of maintaining them inside of Xen and inside of OSes. If
we switch to emulation as much as possible when it makes sense we will
only have the burden of maintaining the hypervisor side.

We will anyway need to provide a local APIC at least in order to benefit
from posted-interrupts (and probably new hw features as they come up),
and the only way to do it is to provide an interface that's exactly the
same as on native.

> 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.  I'd be much happier saying that PCI passthrough
> requires PV or legacy HVM until a better plan can be found
> (e.g. depriv helpers).

That would be great, and it's indeed my prefer route, but if we cannot
hold PCI-passthough until we have the depriv mode in place it would have
to be done inside the hypervisor. Now that we have Kconfig it could even
be left out if someone doesn't really trust the code.

Roger.


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