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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jan 21, 2016 at 01:23:31AM +0800, Xiao Guangrong wrote:
> 
> 
> On 01/21/2016 01:18 AM, 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).
> 
> Ah, ACPI eliminates this E820 entry.
> 
> >
> >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.
> >
> 
> Interesting. I did not consider using NVDIMM as DMA. Do you have usecase for 
> this
> kind of NVDIMM usage?

An easy one is iSCSI target. You could have an SR-IOV NIC that would have TCM
enabled (CONFIG_TCM_FILEIO or CONFIG_TCM_IBLOCK). Mount an file on the 
/dev/pmem0
(using DAX enabled FS) and export it as iSCSI LUN. The traffic would go over an 
SR-IOV NIC.

The DMA transactions would be SR-IOV NIC <-> NVDIMM.


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