[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 10/16] dimm: add busy slot check and slot auto-a

From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 10/16] dimm: add busy slot check and slot auto-allocation
Date: Wed, 24 Jul 2013 10:36:22 +0200

On Tue, 23 Jul 2013 19:09:26 +0200
Paolo Bonzini <address@hidden> wrote:

> Il 23/07/2013 18:23, Igor Mammedov ha scritto:
> > - if slot property is not specified on -device/device_add command,
> > treat default value as request for assigning DimmDevice to
> > the first free slot.
> Even with "-m" instead of "-numa mem", I think this is problematic
> because we still need to separate the host and guest parts of the DIMM
> device.  "-numa mem" (or the QMP command that Wanlong added) will be
> necessary to allocate memory on the host side before adding a DIMM.
why not do host allocation part at the same time when DIMM is added, is
there a real need to separate DIMM device?

I probably miss something but -numa mem option and co aside what problem
couldn't be solved during DIMM device initialization and would require
a split DIMM device?

> So slots will have three states: free (created with "-m"), allocated (a
> free slot moves to this state with "-numa mem...,populated=no" when
> migrating, or with the QMP command for regular hotplug), populated (an
> allocated slot moves to this state with "-device dimm").
> You would be able to plug a DIMM only into an allocated slot, and the
> size will be specified on the slot rather than the DIMM device.
'slot' property is there only for migration sake to provide stable
numeric ID for QEMU<->ACPI BIOS interface. It's not used for any other
purpose and wasn't intended for any other usage..

on baremetal slot has noting to do with size of plugged in DIMM, why we
would model it other way if it only brings problems: like predefined size,
allocated, free etc. I think slot should be either free or busy.

> In general, I don't think free slots should be managed by the DimmBus,
> and host vs. guest separation should be there even if we accept your
> "-m" extension (doesn't look bad at all, I must say).
> Paolo

reply via email to

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