All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, Bandan Das <bsd@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] KVM: x86: Add host physical address width capability
Date: Fri, 10 Jul 2015 16:59:19 +0200	[thread overview]
Message-ID: <559FDDC7.3060306@redhat.com> (raw)
In-Reply-To: <559FDD44.1020008@redhat.com>



On 10/07/2015 16:57, Laszlo Ersek wrote:
> > > ... In any case, please understand that I'm not campaigning for this
> > > warning :) IIRC the warning was your (very welcome!) idea after I
> > > reported the problem; I'm just trying to ensure that the warning match
> > > the exact issue I encountered.
> > 
> > Yup.  I think the right thing to do would be to hide memory above the
> > limit.
> How so?
> 
> - The stack would not be doing what the user asks for. Pass -m <a_lot>,
> and the guest would silently see less memory. If the user found out,
> he'd immediately ask (or set out debugging) why. I think if the user's
> request cannot be satisfied, the stack should fail hard.

That's another possibility.  I think both of them are wrong depending on
_why_ you're using "-m <a lot>" in the first place.

Considering that this really happens (on Xeons) only for 1TB+ guests,
it's probably just for debugging and then hiding the memory makes some
sense.

Paolo

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, Bandan Das <bsd@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] KVM: x86: Add host physical address width capability
Date: Fri, 10 Jul 2015 16:59:19 +0200	[thread overview]
Message-ID: <559FDDC7.3060306@redhat.com> (raw)
In-Reply-To: <559FDD44.1020008@redhat.com>



On 10/07/2015 16:57, Laszlo Ersek wrote:
> > > ... In any case, please understand that I'm not campaigning for this
> > > warning :) IIRC the warning was your (very welcome!) idea after I
> > > reported the problem; I'm just trying to ensure that the warning match
> > > the exact issue I encountered.
> > 
> > Yup.  I think the right thing to do would be to hide memory above the
> > limit.
> How so?
> 
> - The stack would not be doing what the user asks for. Pass -m <a_lot>,
> and the guest would silently see less memory. If the user found out,
> he'd immediately ask (or set out debugging) why. I think if the user's
> request cannot be satisfied, the stack should fail hard.

That's another possibility.  I think both of them are wrong depending on
_why_ you're using "-m <a lot>" in the first place.

Considering that this really happens (on Xeons) only for 1TB+ guests,
it's probably just for debugging and then hiding the memory makes some
sense.

Paolo

  reply	other threads:[~2015-07-10 14:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08 22:36 [PATCH] KVM: x86: Add host physical address width capability Bandan Das
2015-07-08 22:36 ` [Qemu-devel] " Bandan Das
2015-07-09  6:09 ` Paolo Bonzini
2015-07-09  6:09   ` [Qemu-devel] " Paolo Bonzini
2015-07-09  6:43   ` Laszlo Ersek
2015-07-09  6:43     ` [Qemu-devel] " Laszlo Ersek
2015-07-09 12:41     ` Paolo Bonzini
2015-07-09 12:41       ` [Qemu-devel] " Paolo Bonzini
2015-07-09 18:32       ` Bandan Das
2015-07-09 18:32         ` [Qemu-devel] " Bandan Das
2015-07-09 18:57         ` Laszlo Ersek
2015-07-09 18:57           ` [Qemu-devel] " Laszlo Ersek
2015-07-09 18:57           ` Laszlo Ersek
2015-07-09 20:02           ` Bandan Das
2015-07-09 20:02             ` [Qemu-devel] " Bandan Das
2015-07-09 20:02             ` Bandan Das
2015-07-09 20:15             ` Laszlo Ersek
2015-07-09 20:15               ` [Qemu-devel] " Laszlo Ersek
2015-07-10  3:37             ` Bandan Das
2015-07-10  3:37               ` [Qemu-devel] " Bandan Das
2015-07-10  3:37               ` Bandan Das
2015-07-10 14:13           ` Paolo Bonzini
2015-07-10 14:13             ` [Qemu-devel] " Paolo Bonzini
2015-07-10 14:57             ` Laszlo Ersek
2015-07-10 14:57               ` [Qemu-devel] " Laszlo Ersek
2015-07-10 14:59               ` Paolo Bonzini [this message]
2015-07-10 14:59                 ` Paolo Bonzini
2015-07-10 15:06                 ` Laszlo Ersek
2015-07-10 15:06                   ` [Qemu-devel] " Laszlo Ersek
2015-07-10 15:06                   ` Laszlo Ersek
2015-07-10 15:45                   ` Bandan Das
2015-07-10 15:45                     ` [Qemu-devel] " Bandan Das

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=559FDDC7.3060306@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bsd@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lersek@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /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.