[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines
From: |
Cornelia Huck |
Subject: |
Re: [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines |
Date: |
Thu, 2 Apr 2020 12:27:03 +0200 |
On Thu, 2 Apr 2020 11:25:34 +0200
Christian Borntraeger <address@hidden> wrote:
> On 02.04.20 11:22, Cornelia Huck wrote:
> > On Wed, 1 Apr 2020 15:14:12 +0200
> > David Hildenbrand <address@hidden> wrote:
> >
> >> On 01.04.20 14:37, Christian Borntraeger wrote:
> >
> >>> +static ram_addr_t s390_fixup_ram_size(ram_addr_t sz)
> >>> +{
> >>> + /* same logic as in sclp.c */
> >>> + int increment_size = 20;
> >>> + ram_addr_t newsz;
> >>> +
> >>> + while ((sz >> increment_size) > MAX_STORAGE_INCREMENTS) {
> >>> + increment_size++;
> >>> + }
> >>> + newsz = sz >> increment_size << increment_size;
> >>> +
> >>> + if (sz != newsz) {
> >>> + qemu_printf("Ram size %" PRIu64 "MB was fixed up to %" PRIu64
> >>> + "MB to match machine restrictions. Consider updating
> >>> "
> >>> + "the guest definition.i\n", sz / MiB, newsz / MiB);
> >>>
> >>
> >> Not sure if news/zs will be printed correctly in case ram_addr_t !=
> >> uint64_t.
> >
> > RAM_ADDR_FMT might be the right thing to use here?
>
> I tried that but it returns a hex value in bytes. This is unusable. Thats why
> I divided
> by MiB.
Nod.
> We could simply do an u64 cast?
Not sure if we might end up with "cast to integer of different length"
values on some platforms (that I unfortunately don't have around to
test). I hate that stuff.
Re: [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines, Igor Mammedov, 2020/04/01
Re: [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines, Igor Mammedov, 2020/04/02
Re: [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines, Christian Borntraeger, 2020/04/02
Re: [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines, Igor Mammedov, 2020/04/02