[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 21.01.16 at 10:10, <guangrong.xiao@xxxxxxxxxxxxxxx> 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.

Why would this be different from ordinary memory hotplug, where
Dom0 deals with the ACPI CA interaction, notifying Xen about the
added memory?

> b) some _DSMs control PMEM so you should filter out these kind of _DSMs and
>     handle them in hypervisor.

Not if (see above) following the model we currently have in place.

> c) hypervisor should mange PMEM resource pool and partition it to multiple
>     VMs.

Yes.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.