All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bandan Das <bsd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	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 11:45:15 -0400	[thread overview]
Message-ID: <jpgr3oghv90.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <559FDF8F.1020109@redhat.com> (Laszlo Ersek's message of "Fri, 10 Jul 2015 17:06:55 +0200")

Laszlo Ersek <lersek@redhat.com> writes:

> On 07/10/15 16:59, Paolo Bonzini wrote:
>> 
>> 
>> 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,
>
> I reported this issue because I ran into it with a ~64GB guest. From my
> /proc/cpuinfo:
>
> model name      : Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
> address sizes   : 36 bits physical, 48 bits virtual
>
> I was specifically developing 64GB+ support for OVMF, and this
> limitation caused me to think that there was a bug in my OVMF patches.
> (There wasn't.) An error message from QEMU, advising me to turn off EPT,
> would have saved me many hours.

Right, I specifically reserved a system with 36 bits physical to reproduce
this and it was very easy to reproduce. If it's a hardware bug, I would say,
it's a very annoying one (if not serious). I wonder if Intel folks can
chime in.

> Thanks
> Laszlo
>
>> it's probably just for debugging and then hiding the memory makes some
>> sense.
Actually, I agree with Laszlo here. Hiding memory is synonymous to forcing the
user to use less for the -m argument as is failing. But failing and letting the
user do it himself can save hours of debugging.

Regards,
The confused teenager who can't make up his mind.

>> Paolo
>> 

WARNING: multiple messages have this Message-ID (diff)
From: Bandan Das <bsd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	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 11:45:15 -0400	[thread overview]
Message-ID: <jpgr3oghv90.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <559FDF8F.1020109@redhat.com> (Laszlo Ersek's message of "Fri, 10 Jul 2015 17:06:55 +0200")

Laszlo Ersek <lersek@redhat.com> writes:

> On 07/10/15 16:59, Paolo Bonzini wrote:
>> 
>> 
>> 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,
>
> I reported this issue because I ran into it with a ~64GB guest. From my
> /proc/cpuinfo:
>
> model name      : Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
> address sizes   : 36 bits physical, 48 bits virtual
>
> I was specifically developing 64GB+ support for OVMF, and this
> limitation caused me to think that there was a bug in my OVMF patches.
> (There wasn't.) An error message from QEMU, advising me to turn off EPT,
> would have saved me many hours.

Right, I specifically reserved a system with 36 bits physical to reproduce
this and it was very easy to reproduce. If it's a hardware bug, I would say,
it's a very annoying one (if not serious). I wonder if Intel folks can
chime in.

> Thanks
> Laszlo
>
>> it's probably just for debugging and then hiding the memory makes some
>> sense.
Actually, I agree with Laszlo here. Hiding memory is synonymous to forcing the
user to use less for the -m argument as is failing. But failing and letting the
user do it himself can save hours of debugging.

Regards,
The confused teenager who can't make up his mind.

>> Paolo
>> 

  reply	other threads:[~2015-07-10 15:45 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
2015-07-10 14:59                 ` [Qemu-devel] " 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 [this message]
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=jpgr3oghv90.fsf@linux.bootlegged.copy \
    --to=bsd@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lersek@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --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.