qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] pc-dimm: No numa option shouldn't break hot


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 1/2] pc-dimm: No numa option shouldn't break hotplug memory feature
Date: Tue, 23 Sep 2014 13:12:18 +0200

On Tue, 23 Sep 2014 18:11:35 +0800
zhanghailiang <address@hidden> wrote:

> On 2014/9/23 16:58, Tang Chen wrote:
> >
> > On 09/23/2014 04:40 PM, Igor Mammedov wrote:
> >> ......
> >> It's fine to use SRAT for these purposes on baremetal NUMA systems since
> >> due to used chipset constrains it's possible statically allocate ranges
> >> for every possible DIMM socket.
> >> However SRAT(which is optional table BTW) entries are not mandatory
> >> and override-able by ACPI Device's _PXM/_CRS methods replacing needs
> >> for SRAT entries and QEMU uses this fact by supplying these methods.
> >> QEMU adds FAKE SRAT entry only to workaround Windows limitation,
> >> and for nothing else.
> >>
> >> I think Linux does not violate ACPI spec and behaves as expected, moreover
> >> it's more correct than Windows since memory hotplug will work on non NUMA
> >> machines as well.
> >>
> >> Hence I think this patch is correct and allows memory hotplug in absence
> >> of NUMA configuration. It also would allow to use pc-dimm as replacement
> >> for initial memory for non-NUMA configs (which is on my TODO list)
> >>
> >> As for the Windows, QEMU has no idea what OS it would be running,
> >> I see 2 ways to solve issue:
> >>   1. user should know that memory hotplug on Windows requires NUMA machine
> >>      and specify "-numa ..." option for this case.
> >>     (I've discussed this with libvirt folks and was promised that
> >>      if user enables memory hotplug, libvirt would provide "-numa" option
> >>      to workaround Windows issue)
> >>
> >>   2. QEMU could unconditionally create single NUMA if memory hotplug is
> >>      enabled. (but that should be enable only for 2.2 or late machines
> >>      to avoid migration issues)
> >>
> > I prefer 2. I'll try to send patches for it if Zhang is also OK with it.
> >
> 
> Yep, It is a good scheme to create a dummy NUMA unconditionally.
> But Igor has said there are migration issues for this scenario, do you know 
> what's
> it? ;)
> 
'-numa' will add SRAT table to ACPI tables blob, as result it will grow in size,
depending on config options #cpus, #dimms, #pci-bridges it could trigger
issues we've had with prior 2.1 was released.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]