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
linkDIMM'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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
