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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

As far as I am aware, the remaining 10% is a bus 0, and PCI-complient
bus handling (a few extra registers in legacy PCI configuration space),
to be able to steer all other PCI related accesses to the appropriate
ioreq server, and splitting of the two GPE blocks.

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.

>   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).

The current pci-front/back and Qemu-based methods have substantial
architectural deficiencies, and are incredibly fragile to change.  When
was the last XSA to PCI Passthrough which didn't end up requiring
further bugfixes to undo the collateral damage?

It is my hope that we can correct the architecture as part of developing
HVMLite (at which point HVM will immediately benefit), and vastly simply
the device model interfaces.  Of course, if during the course of
development this proves not to be the case, we will have to sit down and
replan.

From where I am sitting, most of the risks are already present, and the
potential benefits vastly outweigh the downsides.

~Andrew

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