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

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 01/20/16 12:18, Konrad Rzeszutek Wilk wrote:
> > >>>>c) hotplug support
> > >>>
> > >>>How does that work? Ah the _DSM will point to the new ACPI NFIT for the 
> > >>>OS
> > >>>to scan. That would require the hypervisor also reading this for it to
> > >>>update it's data-structures.
> > >>
> > >>Similar as you said. The NVDIMM root device in SSDT/DSDT dedicates a new 
> > >>interface,
> > >>_FIT, which return the new NFIT once new device hotplugged. And yes, 
> > >>domain 0 is
> > >>the better place handing this case too.
> > >
> > >That one is a bit difficult. Both the OS and the hypervisor would need to 
> > >know about
> > >this (I think?). dom0 since it gets the ACPI event and needs to process 
> > >it. Then
> > >the hypervisor needs to be told so it can slurp it up.
> > 
> > Can dom0 receive the interrupt triggered by device hotplug? If yes, we can 
> > let dom0
> 
> Yes of course it can.
> > handle all the things like native. If it can not, dom0 can interpret ACPI 
> > and fetch
> > the irq info out and tell hypervior to pass the irq to dom0, it is doable?
> > 
> > >
> > >However I don't know if the hypervisor needs to know all the details of an
> > >NVDIMM - or just the starting and ending ranges so that when an guest is 
> > >created
> > >and the VT-d is constructed - it can be assured that the ranges are valid.
> > >
> > >I am not an expert on the P2M code - but I think that would need to be 
> > >looked
> > >at to make sure it is OK with stitching an E820_NVDIMM type "MFN" into an 
> > >guest PFN.
> > 
> > We do better do not use "E820" as it lacks some advantages of ACPI, such 
> > as, NUMA, hotplug,
> > lable support (namespace)...
> 
> <hand-waves> I don't know what QEMU does for guests? I naively assumed it 
> would
> create an E820_NVDIMM along with the ACPI MADT NFIT tables (and the SSDT to 
> have
> the _DSM).
>

ACPI 6 defines E820 type 7 for pmem (see table 15-312 in Section 15)
and legacy ones may use the non-standard type 12 (and even older ones
may use type 6, but linux does not consider type 6 any more), but
hot-plugged NVDIMM may not appear in E820. Still think it's better to
let dom0 linux that already has enough drivers handle all these device
probing tasks.

> Either way what I think you need to investigate is what is neccessary for the
> Xen hypervisor VT-d code (IOMMU) to have an entry which is the system address 
> for
> the NVDIMM. Based on that - you will know what kind of exposure the hypervisor
> needs to the _FIT and NFIT tables.
>
> (Adding Feng Wu, the VT-d maintainer).

I haven't considered VT-d at all. From your example in another reply,
it looks like that VT-d code needs to be aware of the address space
range of NVDIMM, otherwise that example would not work. If so, maybe
we can let dom0 linux kernel report the address space ranges of
detected NVDIMM devices to Xen hypervisor. Anyway, I'll investigate
this issue.

Haozhong

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