On Mon, Feb 15, 2016 at 06:13:38PM +0800, Xiao Guangrong wrote: > > > On 02/15/2016 05:18 PM, Michael S. Tsirkin wrote: > >On Mon, Feb 15, 2016 at 10:11:05AM +0100, Igor Mammedov wrote: > >>On Sun, 14 Feb 2016 13:57:27 +0800 > >>Xiao Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx> wrote: > >> > >>>On 02/08/2016 07:03 PM, Igor Mammedov wrote: > >>>>On Wed, 13 Jan 2016 02:50:05 +0800 > >>>>Xiao Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx> wrote: > >>>> > >>>>>32 bits IO port starting from 0x0a18 in guest is reserved for NVDIMM > >>>>>ACPI emulation. The table, NVDIMM_DSM_MEM_FILE, will be patched into > >>>>>NVDIMM ACPI binary code > >>>>> > >>>>>OSPM uses this port to tell QEMU the final address of the DSM memory > >>>>>and notify QEMU to emulate the DSM method > >>>>Would you need to pass control to QEMU if each NVDIMM had its whole > >>>>label area MemoryRegion mapped right after its storage MemoryRegion? > >>>> > >>> > >>>No, label data is not mapped into guest's address space and it only > >>>can be accessed by DSM method indirectly. > >>Yep, per spec label data should be accessed via _DSM but question > >>wasn't about it, > > Ah, sorry, i missed your question. > > >>Why would one map only 4Kb window and serialize label data > >>via it if it could be mapped as whole, that way _DMS method will be > >>much less complicated and there won't be need to add/support a protocol > >>for its serialization. > >> > > > >Is it ever accessed on data path? If not I prefer the current approach: > > The label data is only accessed via two DSM commands - Get Namespace Label > Data and Set Namespace Label Data, no other place need to be emulated. > > >limit the window used, the serialization protocol seems rather simple. > > > > Yes. > > Label data is at least 128k which is big enough for BIOS as it allocates > memory at 0 ~ 4G which is tight region. It also needs guest OS to support > lager max-xfer (the max size that can be transferred one time), the size > in current Linux NVDIMM driver is 4k. > > However, using lager DSM buffer can help us to simplify NVDIMM hotplug for > the case that too many nvdimm devices present in the system and their FIT > info can not be filled into one page. Each PMEM-only device needs 0xb8 bytes > and we can append 256 memory devices at most, so 12 pages are needed to > contain this info. The prototype we implemented is using ourself-defined > protocol to read piece of _FIT and concatenate them before return to Guest, > please refer to: > https://github.com/xiaogr/qemu/commit/c46ce01c8433ac0870670304360b3c4aa414143a > > As 12 pages are not small region for BIOS and the _FIT size may be extended in the > future development (eg, if PBLK is introduced) i am not sure if we need this. Of > course, another approach to simplify it is that we limit the number of NVDIMM > device to make sure their _FIT < 4k. > > > Bigger buffer would only be reasonable in 64 bit window (>4G), <4G area is too busy for that. Would that be a problem? -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
