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>,
	kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] KVM: x86: Add host physical address width capability
Date: Thu, 9 Jul 2015 14:41:09 +0200	[thread overview]
Message-ID: <559E6BE5.4030000@redhat.com> (raw)
In-Reply-To: <559E180E.8080308@redhat.com>



On 09/07/2015 08:43, Laszlo Ersek wrote:
> On 07/09/15 08:09, Paolo Bonzini wrote:
>>
>>
>> On 09/07/2015 00:36, Bandan Das wrote:
>>> Let userspace inquire the maximum physical address width
>>> of the host processors; this can be used to identify maximum
>>> memory that can be assigned to the guest.
>>>
>>> Reported-by: Laszlo Ersek <lersek@redhat.com>
>>> Signed-off-by: Bandan Das <bsd@redhat.com>
>>> ---
>>>  arch/x86/kvm/x86.c       | 3 +++
>>>  include/uapi/linux/kvm.h | 1 +
>>>  2 files changed, 4 insertions(+)
>>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index bbaf44e..97d6746 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -2683,6 +2683,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>  	case KVM_CAP_NR_MEMSLOTS:
>>>  		r = KVM_USER_MEM_SLOTS;
>>>  		break;
>>> +	case KVM_CAP_PHY_ADDR_WIDTH:
>>> +		r = boot_cpu_data.x86_phys_bits;
>>> +		break;
>>
>> Userspace can just use CPUID, can't it?
> 
> I believe KVM's cooperation is necessary, for the following reason:
> 
> The truncation only occurs when the guest-phys <-> host-phys translation
> is done in hardware, *and* the phys bits of the host processor are
> insufficient to represent the highest guest-phys address that the guest
> will ever face.
> 
> The first condition (of course) means that the truncation depends on EPT
> being enabled. (I didn't test on AMD so I don't know if RVI has the same
> issue.) If EPT is disabled, either because the host processor lacks it,
> or because the respective kvm_intel module parameter is set so, then the
> issue cannot be experienced.
> 
> Therefore I believe a KVM patch is necessary.
> 
> However, this specific patch doesn't seem sufficient; it should also
> consider whether EPT is enabled. (And the ioctl should be perhaps
> renamed to reflect that -- what QEMU needs to know is not the raw
> physical address width of the host processor, but whether that width
> will cause EPT to silently truncate high guest-phys addresses.)

Right; if you want to consider whether EPT is enabled (which is the
right thing to do, albeit it makes for a much bigger patch) a KVM patch
is necessary.  In that case you also need to patch the API documentation.

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>,
	kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] KVM: x86: Add host physical address width capability
Date: Thu, 9 Jul 2015 14:41:09 +0200	[thread overview]
Message-ID: <559E6BE5.4030000@redhat.com> (raw)
In-Reply-To: <559E180E.8080308@redhat.com>



On 09/07/2015 08:43, Laszlo Ersek wrote:
> On 07/09/15 08:09, Paolo Bonzini wrote:
>>
>>
>> On 09/07/2015 00:36, Bandan Das wrote:
>>> Let userspace inquire the maximum physical address width
>>> of the host processors; this can be used to identify maximum
>>> memory that can be assigned to the guest.
>>>
>>> Reported-by: Laszlo Ersek <lersek@redhat.com>
>>> Signed-off-by: Bandan Das <bsd@redhat.com>
>>> ---
>>>  arch/x86/kvm/x86.c       | 3 +++
>>>  include/uapi/linux/kvm.h | 1 +
>>>  2 files changed, 4 insertions(+)
>>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index bbaf44e..97d6746 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -2683,6 +2683,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>  	case KVM_CAP_NR_MEMSLOTS:
>>>  		r = KVM_USER_MEM_SLOTS;
>>>  		break;
>>> +	case KVM_CAP_PHY_ADDR_WIDTH:
>>> +		r = boot_cpu_data.x86_phys_bits;
>>> +		break;
>>
>> Userspace can just use CPUID, can't it?
> 
> I believe KVM's cooperation is necessary, for the following reason:
> 
> The truncation only occurs when the guest-phys <-> host-phys translation
> is done in hardware, *and* the phys bits of the host processor are
> insufficient to represent the highest guest-phys address that the guest
> will ever face.
> 
> The first condition (of course) means that the truncation depends on EPT
> being enabled. (I didn't test on AMD so I don't know if RVI has the same
> issue.) If EPT is disabled, either because the host processor lacks it,
> or because the respective kvm_intel module parameter is set so, then the
> issue cannot be experienced.
> 
> Therefore I believe a KVM patch is necessary.
> 
> However, this specific patch doesn't seem sufficient; it should also
> consider whether EPT is enabled. (And the ioctl should be perhaps
> renamed to reflect that -- what QEMU needs to know is not the raw
> physical address width of the host processor, but whether that width
> will cause EPT to silently truncate high guest-phys addresses.)

Right; if you want to consider whether EPT is enabled (which is the
right thing to do, albeit it makes for a much bigger patch) a KVM patch
is necessary.  In that case you also need to patch the API documentation.

Paolo

  reply	other threads:[~2015-07-09 12:41 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 [this message]
2015-07-09 12:41       ` 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
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=559E6BE5.4030000@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.