Re: [RFC PATCH v3 06/19] Implement "-dimm" command line option

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

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux