Re: [Xen-devel] [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/01/16 09:10, Xiao Guangrong wrote:
>
>
> On 01/21/2016 04:53 PM, Jan Beulich wrote:
>>>>> On 21.01.16 at 09:25, <guangrong.xiao@xxxxxxxxxxxxxxx> wrote:
>>> On 01/21/2016 04:18 PM, Jan Beulich wrote:
>>>> Yes. But then - other than you said above - it still looks to me as
>>>> if the split between PMEM and PBLK is arranged for by firmware?
>>>
>>> Yes. But OS/Hypervisor is not excepted to dynamically change its
>>> configure
>>> (re-split),
>>> i,e, for PoV of OS/Hypervisor, it is static.
>>
>> Exactly, that has been my understanding. And hence the PMEM part
>> could be under the hypervisor's control, while the PBLK part could be
>> Dom0's responsibility.
>>
>
> I am not sure if i have understood your point. What your suggestion is
> that
> leave PMEM for hypervisor and all other parts (PBLK and _DSM handling) to
> Dom0? If yes, we should:
> a) handle hotplug in hypervisor (new PMEM add/remove) that causes
> hyperivsor
>    interpret ACPI SSDT/DSDT.
> b) some _DSMs control PMEM so you should filter out these kind of
> _DSMs and
>    handle them in hypervisor.
> c) hypervisor should mange PMEM resource pool and partition it to
> multiple
>    VMs.

It is not possible for Xen to handle ACPI such as this.

There can only be one OSPM on a system, and 9/10ths of the functionality
needing it already lives in Dom0.

The only rational course of action is for Xen to treat both PBLK and
PMEM as "devices" and leave them in Dom0's hands.

~Andrew

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