All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: David Hildenbrand <david@redhat.com>,
	Alexander Graf <agraf@suse.de>, Thomas Huth <thuth@redhat.com>,
	Halil Pasic <pasic@linux.vnet.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/1] s390-ccw-virtio: allow for systems larger that 7.999TB
Date: Mon, 11 Dec 2017 16:11:29 +0100	[thread overview]
Message-ID: <20171211161129.5c0005f3.cohuck@redhat.com> (raw)
In-Reply-To: <585800a9-cab8-a79a-048a-380de5a54f6c@de.ibm.com>

On Mon, 11 Dec 2017 15:04:13 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 12/11/2017 02:55 PM, David Hildenbrand wrote:
> > On 11.12.2017 13:21, Christian Borntraeger wrote:  
> >> KVM does not allow memory regions > KVM_MEM_MAX_NR_PAGES, basically
> >> limiting the memory per slot to 8TB-4k. As memory slots on s390/kvm must
> >> be a multiple of 1MB we need start a new memory region if we cross
> >> 8TB-1M.
> >>
> >> With that (and optimistic overcommitment in the kernel) I was able to
> >> start a 24TB guest on a 1TB system.
> >>
> >> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> >> ---
> >>  hw/s390x/s390-virtio-ccw.c | 28 +++++++++++++++++++++++++---
> >>  1 file changed, 25 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> >> index 8425534..073f6ed 100644
> >> --- a/hw/s390x/s390-virtio-ccw.c
> >> +++ b/hw/s390x/s390-virtio-ccw.c
> >> @@ -154,14 +154,36 @@ static void virtio_ccw_register_hcalls(void)
> >>                                     virtio_ccw_hcall_early_printk);
> >>  }
> >>  
> >> +/*
> >> + * KVM does only support memory slots up to KVM_MEM_MAX_NR_PAGES pages
> >> + * as the dirty bitmap must be managed by bitops that take an int as
> >> + * position indicator. If we have a guest beyond that we will split off
> >> + * new subregions. The split must happen on a segment boundary (1MB).
> >> + */
> >> +#define KVM_MEM_MAX_NR_PAGES ((1UL << 31) - 1)
> >> +#define SEG_MSK (~0xfffffULL)
> >> +#define KVM_SLOT_MAX_BYTES ((KVM_MEM_MAX_NR_PAGES * TARGET_PAGE_SIZE) & SEG_MSK)  
> > 
> > Just wondering if we could get into trouble when calculating
> > 
> > KVM_MEM_MAX_NR_PAGES * TARGET_PAGE_SIZE  
> 
> maybe just using 1ULL instead of 1UL?

I vote for 1ULL, just to be on the safe side.

> 
> 
> > 
> > on a host with sizeof(long) == 4
> > 
> > could it wrap? (e.g. crazy mingw stuff)

FWIW, both the 1UL and 1ULL variants compile fine for me both when
building natively and cross-building with mingw.

  reply	other threads:[~2017-12-11 15:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-11 12:21 [Qemu-devel] [PATCH v3 1/1] s390-ccw-virtio: allow for systems larger that 7.999TB Christian Borntraeger
2017-12-11 13:55 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2017-12-11 14:04   ` Christian Borntraeger
2017-12-11 15:11     ` Cornelia Huck [this message]
2017-12-14 13:21 ` [Qemu-devel] " Cornelia Huck
2017-12-14 13:26   ` David Hildenbrand
2017-12-14 13:28     ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171211161129.5c0005f3.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.