On 04/19/2012 09:08 AM, Vasilis Liaskovitis wrote:
This is a prototype for ACPI memory hotplug on x86_64 target. Based on some earlier work and comments from Gleb.
Memslot devices are modeled with a new qemu command line
"-memslot id=name,start=start_addr,size=sz,node=pxm"
Hi,
For 1.2, I'd really like to focus on refactoring the PC machine as described in this series:
https://github.com/aliguori/qemu/commits/qom-rebase.12
I'd like to represent the guest memory as a "DIMM" device.
In terms of this proposal, I would then expect that the i440fx device would have a num_dimms property that controlled how many link<DIMM>'s it had. Hotplug would consist of creating a DIMM at run time and connecting it to the appropriate link.
One thing that's not clear to me is how the start/size fits in. On bare metal, is this something that's calculated by the firmware during start up and then populated in ACPI? Does it do something like take the largest possible DIMM size that it supports and fill out the table?
At any rate, I think we should focus on modeling this in QOM verses adding a new option and hacking at the existing memory init code.
Regards,
Anthony Liguori
Hi,
On Thu, Apr 19, 2012 at 09:49:31AM -0500, Anthony Liguori wrote:
On 04/19/2012 09:08 AM, Vasilis Liaskovitis wrote:
This is a prototype for ACPI memory hotplug on x86_64 target. Based on some earlier work and comments from Gleb.
Memslot devices are modeled with a new qemu command line
"-memslot id=name,start=start_addr,size=sz,node=pxm"
Hi,
For 1.2, I'd really like to focus on refactoring the PC machine as described in this series:
https://github.com/aliguori/qemu/commits/qom-rebase.12
I'd like to represent the guest memory as a "DIMM" device.
In terms of this proposal, I would then expect that the i440fx device would have a num_dimms property that controlled how many link<DIMM>'s it had. Hotplug would consist of creating a DIMM at run time and connecting it to the appropriate link.
ok, makes sense.
One thing that's not clear to me is how the start/size fits in. On bare metal, is this something that's calculated by the firmware during start up and then populated in ACPI? Does it do something like take the largest possible DIMM size that it supports and fill out the table?
The current series works as follows: For each DIMM/memslot option, firmware constructs a QWordMemory ACPI object (see ACPI spec, ASL 18.5.95). This object has AddressMinimum, AddressMaximum, RangeLength fields. The first of these corresponds directly to the start attribute, the third corresponds to size, and the second is derived from both.
On bare metal, I believe the firmware detects the actual DIMM devices and their size and calculates the physical offset (AddressMinimum) for each, taking into account possible PCI hole. I doubt the largest possible DIMM size is used, since a hotplug entity/event should correspond to a physical device. (Kevin or Gleb may have a better idea of what real metal firmware usually does).
Perhaps you are suggesting having a predefined number of equally sized DIMMs as being hotplug-able? This way no memslot/DIMM config would have to be passed by the user at the command line for each DIMM.
In this series, the user-defined memslot options pass the desired DIMM descriptions to SeaBIOS, which then builds the aforementioned objects.(I assume it would be possible to pass this info with normal "-device" commands, after proper qom-ification)
At any rate, I think we should focus on modeling this in QOM verses adding a new option and hacking at the existing memory init code.
agreed. I will take a look into qom-rebase.
thanks,
- Vasilis
-
Anthony Liguori -
Vasilis Liaskovitis