On Thu, Oct 18, 2012 at 12:33 PM, Avi Kivity <avi@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
