[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |