Re: [SeaBIOS] [RFC PATCH v3 06/19] Implement "-dimm" command line option
On 10/18/2012 11:27 AM, Vasilis Liaskovitis wrote:
On Wed, Oct 17, 2012 at 12:03:51PM +0200, Avi Kivity wrote:
On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
I don't think so, but probably there's a limit of DIMMs that real controllers have, something like 8 max.
In the case of i440fx specifically, do you mean that we should model the DRB (Dram row boundary registers in section 3.2.19 of the i440fx spec) ?
The i440fx DRB registers only supports up to 8 DRAM rows (let's say 1 row maps 1-1 to a DimmDevice for this discussion) and only supports up to 2GB of memory afaict (bit 31 and above is ignored).
I 'd rather not model this part of the i440fx - having only 8 DIMMs seems too restrictive. The rest of the patchset supports up to 255 DIMMs so it would be a waste imho to model an old pc memory controller that only supports 8 DIMMs.
There was also an old discussion about i440fx modeling here: https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02705.html the general direction was that i440fx is too old and we don't want to precisely emulate the DRB registers, since they lack flexibility.
Possible solutions:
1) is there a newer and more flexible chipset that we could model?
Look for q35 on this list.
thanks, I 'll take a look. It sounds like the other options below are more straightforward now, but let me know if you prefer q35 integration as a priority.
At least validate that what you're doing fits with how q35 works.
We could for example model: - an 8-bit non-cumulative register for each DIMM, denoting how many 128MB chunks it contains. This allowes 32GB for each DIMM, and with 255 DIMMs we describe a bit less than 8TB. These registers require 255 bytes. - a 16-bit cumulative register for each DIMM again for 128MB chunks. This allows us to describe 8TB of memory (but the registers take up double the space, because they describe cumulative memory amounts)
There is no reason to save space. Why not have two 64-bit registers per DIMM, one describing the size and the other the base address, both in bytes? Use a few low order bits for control.
Do we want this generic scheme above to be tied into the i440fx/pc machine?
Yes. q35 should work according to its own specifications.
Or have it as a separate generic memory bus / pmc usable by others (e.g. in hw/dimm.c)? The 64-bit values you describe are already part of DimmDevice properties, but they are not hardware registers described as part of a chipset.
In terms of control bits, did you want to mimic some other chipset registers? - any examples would be useful.
I don't have any real requirements. Just make it simple and easily accessible to ACPI code.
3) let everything be handled/abstracted by dimmbus - the chipset DRB modelling is not done (at least for i440fx, other machines could). This is the least precise in terms of emulation. On the other hand, if we are not really trying to emulate the real (too restrictive) hardware, does it matter?
We could emulate base memory using the chipset, and extra memory using the scheme above. This allows guests that are tied to the chipset to work, and guests that have more awareness (seabios) to use the extra features.
But if we use the real i440fx pmc DRBs for base memory, this means base memory would be <= 2GB, right?
Sounds like we 'd need to change the DRBs anyway to describe useful amounts of base memory (e.g. 512MB chunks and check against address lines [36:29] can describe base memory up to 64GB, though that's still limiting for very large VMs). But we'd be diverting from the real hardware again.
Then there's no point. Modelling real hardware allows guests written to work against that hardware to function correctly. If you diverge, they won't.
Then we can model base memory with "tweaked" i440fx pmc's DRB registers - we could only use DRB[0] (one DIMM describing all of base memory) or more.
DIMMs would be allowed to be hotplugged in the generic mem-controller scheme only (unless it makes sense to allow hotplug in the remaining pmc DRBs and start using the generic scheme once we run out of emulated DRBs)
440fx seems a lost cause, so we can go wild and just implement pv dimms. For q35 I'd like to stay within the spec. -- error compiling committee.c: too many arguments to function
On Thu, Oct 18, 2012 at 12:33 PM, Avi Kivity <avi@redhat.com> wrote:
On 10/18/2012 11:27 AM, Vasilis Liaskovitis wrote:
On Wed, Oct 17, 2012 at 12:03:51PM +0200, Avi Kivity wrote:
On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
I don't think so, but probably there's a limit of DIMMs that real controllers have, something like 8 max.
In the case of i440fx specifically, do you mean that we should model the DRB (Dram row boundary registers in section 3.2.19 of the i440fx spec) ?
The i440fx DRB registers only supports up to 8 DRAM rows (let's say 1 row maps 1-1 to a DimmDevice for this discussion) and only supports up to 2GB of memory afaict (bit 31 and above is ignored).
I 'd rather not model this part of the i440fx - having only 8 DIMMs seems too restrictive. The rest of the patchset supports up to 255 DIMMs so it would be a waste imho to model an old pc memory controller that only supports 8 DIMMs.
There was also an old discussion about i440fx modeling here: https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02705.html the general direction was that i440fx is too old and we don't want to precisely emulate the DRB registers, since they lack flexibility.
Possible solutions:
1) is there a newer and more flexible chipset that we could model?
Look for q35 on this list.
thanks, I 'll take a look. It sounds like the other options below are more straightforward now, but let me know if you prefer q35 integration as a priority.
At least validate that what you're doing fits with how q35 works.
We could for example model: - an 8-bit non-cumulative register for each DIMM, denoting how many 128MB chunks it contains. This allowes 32GB for each DIMM, and with 255 DIMMs we describe a bit less than 8TB. These registers require 255 bytes. - a 16-bit cumulative register for each DIMM again for 128MB chunks. This allows us to describe 8TB of memory (but the registers take up double the space, because they describe cumulative memory amounts)
There is no reason to save space. Why not have two 64-bit registers per DIMM, one describing the size and the other the base address, both in bytes? Use a few low order bits for control.
Do we want this generic scheme above to be tied into the i440fx/pc machine?
Yes. q35 should work according to its own specifications.
Or have it as a separate generic memory bus / pmc usable by others (e.g. in hw/dimm.c)? The 64-bit values you describe are already part of DimmDevice properties, but they are not hardware registers described as part of a chipset.
In terms of control bits, did you want to mimic some other chipset registers? - any examples would be useful.
I don't have any real requirements. Just make it simple and easily accessible to ACPI code.
3) let everything be handled/abstracted by dimmbus - the chipset DRB modelling is not done (at least for i440fx, other machines could). This is the least precise in terms of emulation. On the other hand, if we are not really trying to emulate the real (too restrictive) hardware, does it matter?
We could emulate base memory using the chipset, and extra memory using the scheme above. This allows guests that are tied to the chipset to work, and guests that have more awareness (seabios) to use the extra features.
But if we use the real i440fx pmc DRBs for base memory, this means base memory would be <= 2GB, right?
Sounds like we 'd need to change the DRBs anyway to describe useful amounts of base memory (e.g. 512MB chunks and check against address lines [36:29] can describe base memory up to 64GB, though that's still limiting for very large VMs). But we'd be diverting from the real hardware again.
Then there's no point. Modelling real hardware allows guests written to work against that hardware to function correctly. If you diverge, they won't.
The guest is also unlikely to want to reprogram the memory controller.
Then we can model base memory with "tweaked" i440fx pmc's DRB registers - we could only use DRB[0] (one DIMM describing all of base memory) or more.
DIMMs would be allowed to be hotplugged in the generic mem-controller scheme only (unless it makes sense to allow hotplug in the remaining pmc DRBs and start using the generic scheme once we run out of emulated DRBs)
440fx seems a lost cause, so we can go wild and just implement pv dimms.
Maybe. But what would be a PV DIMM? Do we need any DIMM-like granularity at all, instead the guest could be told to use a list of RAM regions with arbitrary start and end addresses? Isn't ballooning also related?
For q35 I'd like to stay within the spec.
That may not last forever when machines have terabytes of memory.
-- error compiling committee.c: too many arguments to function
Hi, On Thu, Oct 18, 2012 at 02:33:02PM +0200, Avi Kivity wrote:
On 10/18/2012 11:27 AM, Vasilis Liaskovitis wrote:
On Wed, Oct 17, 2012 at 12:03:51PM +0200, Avi Kivity wrote:
On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
I don't think so, but probably there's a limit of DIMMs that real controllers have, something like 8 max.
In the case of i440fx specifically, do you mean that we should model the DRB (Dram row boundary registers in section 3.2.19 of the i440fx spec) ?
The i440fx DRB registers only supports up to 8 DRAM rows (let's say 1 row maps 1-1 to a DimmDevice for this discussion) and only supports up to 2GB of memory afaict (bit 31 and above is ignored).
I 'd rather not model this part of the i440fx - having only 8 DIMMs seems too restrictive. The rest of the patchset supports up to 255 DIMMs so it would be a waste imho to model an old pc memory controller that only supports 8 DIMMs.
There was also an old discussion about i440fx modeling here: https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02705.html the general direction was that i440fx is too old and we don't want to precisely emulate the DRB registers, since they lack flexibility.
Possible solutions:
1) is there a newer and more flexible chipset that we could model?
Look for q35 on this list.
thanks, I 'll take a look. It sounds like the other options below are more straightforward now, but let me know if you prefer q35 integration as a priority.
At least validate that what you're doing fits with how q35 works.
In terms of pmc modeling, the q35 page http://wiki.qemu.org/Features/Q35 mentions: Refactor i440fx to create i440fx-pmc class ich9: model ICH9 Super I/O chip ich9: make i440fx-pmc a generic PCNorthBridge class and add support for ich9 northbridge is this still the plan? There was an old patchset creating i440fx-pmc here: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg03501.html but I am not sure if it has been dropped or worked on. v3 of the q35 patchset doesn't include a pmc I think. It would be good to know what the current plan regarding pmc modeling (for both q35 and i440fx) is. thanks, - Vasilis
participants (3)
-
Avi Kivity -
Blue Swirl -
Vasilis Liaskovitis