On 02/19/2016 04:08 PM, Michael S. Tsirkin wrote:
On Thu, Feb 18, 2016 at 11:05:23AM +0100, Igor Mammedov wrote:
On Thu, 18 Feb 2016 12:03:36 +0800
Xiao Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx> wrote:
On 02/18/2016 01:26 AM, Michael S. Tsirkin wrote:
On Wed, Feb 17, 2016 at 10:04:18AM +0800, Xiao Guangrong wrote:
As for the rest could that commands go via MMIO that we usually
use for control path?
So both input data and output data go through single MMIO, we need to
introduce a protocol to pass these data, that is complex?
And is any MMIO we can reuse (more complexer？) or we should allocate this
MMIO page （the old question - where to allocated?）?
Maybe you could reuse/extend memhotplug IO interface,
or alternatively as Michael suggested add a vendor specific PCI_Config,
I'd suggest PM device for that (hw/acpi/[piix4.c|ihc9.c])
which I like even better since you won't need to care about which ports
to allocate at all.
Well, if Michael does not object, i will do it in the next version. :)
Sorry, the thread's so long by now that I'm no longer sure what does "it" refer to.
Never mind i saw you were busy on other loops.
"It" means the suggestion of Igor that "map each label area right after each
NVDIMM's data memory"
Michael pointed out that putting label right after each NVDIMM
might burn up to 256GB of address space due to DIMM's alignment for 256 NVDIMMs.
However if address for each label is picked with pc_dimm_get_free_addr()
and label's MemoryRegion alignment is default 2MB then all labels
would be allocated close to each other within a single 1GB range.
That would burn only 1GB for 500 labels which is more than possible 256 NVDIMMs.
I thought about it, once we support hotplug, this means that one will
have to pre-declare how much is needed so QEMU can mark the correct
memory reserved, that would be nasty. Maybe we always pre-reserve 1Gbyte.
Okay but next time we need something, do we steal another Gigabyte?
It seems too much, I'll think it over on the weekend.
It sounds like this approach (reserve-and-allocate) is very similar as the
old propose that dynamically allocates memory from the end of hotplug-mem. :)
--
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
