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

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

El 5/2/16 a les 15:44, Ian Campbell ha escrit:
> On Thu, 2016-02-04 at 20:33 +0100, Roger Pau Monnà wrote:
>> El 4/2/16 a les 19:22, Andrew Cooper ha escrit:
>>> On 04/02/16 17:48, 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?
>>>
>>> I think it would be best to offer an LAPIC by default (to be helpful to
>>> most modern OSes), but leave the option for an administrator to disable
>>> if they specifically don't want one.
>>
>> So this also implies that we will also provide ACPI by default (RSDT,
>> FADT, MADT)? IMHO the local APIC is specially helpful if it comes with a
>> MADT, so that we can do CPU enumeration from it.
> 
> Just to be clear, we aren't talking about _requiring_ all (SMP) PVH guests
> to be ACPI aware are we? Just about providing some of this stuff in ACPI
> format for the benefit of OSes which happen to already be ACPI aware.
> 
> Right?

Yes, that's right. ACPI is just going to be a requirement for
PCI-passthrough, since we don't plan to support pciback/pcifront.

Roger.


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