From: Quan Xu <quan.xu0@gmail.com>
To: Jim Mattson <jmattson@google.com>
Cc: "kvm list" <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"David Hildenbrand" <david@redhat.com>
Subject: Re: [PATCH] KVM: VMX: drop I/O permission bitmaps
Date: Tue, 12 Dec 2017 16:39:30 +0800 [thread overview]
Message-ID: <ea0cb128-68c5-87f3-53b0-ad947f92fc7d@gmail.com> (raw)
In-Reply-To: <CALMp9eS=oC8UiCoj_+V2N6=i5ovwy5WFg9gcFj-PaATYXs+kqQ@mail.gmail.com>
On 2017/12/12 02:08, Jim Mattson wrote:
> Removing these two lines from the initialization of
> field_to_offset_table[] means that vmcs_field_to_offset() will return
> -ENOENT for IO_BITMAP_A or IO_BITMAP_B. Hence, handle_vmread and
> handle_vmwrite will incorrectly report these fields as unsupported
> VMCS components if an L1 hypervisor tries to access them.
I will fix in v2.
Quan
Alibaba Cloud
> On Sun, Dec 10, 2017 at 9:37 PM, Quan Xu <quan.xu0@gmail.com> wrote:
>>
>> On 2017/12/09 01:31, Jim Mattson wrote:
>>> On Fri, Dec 8, 2017 at 2:22 AM, Quan Xu <quan.xu0@gmail.com> wrote:
>>>> From: Quan Xu <quan.xu0@gmail.com>
>>>>
>>>> Since KVM removes the only I/O port 0x80 bypass on Intel hosts,
>>>> clear CPU_BASED_USE_IO_BITMAPS and set CPU_BASED_UNCOND_IO_EXITING
>>>> bit. Then these I/O permission bitmaps are not used at all, so
>>>> drop I/O permission bitmaps.
>>>>
>>>> Signed-off-by: Jim Mattson <jmattson@google.com>
>>>> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
>>>> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
>>>> ---
>>>> arch/x86/kvm/vmx.c | 17 +----------------
>>>> 1 files changed, 1 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>>> index 2fd9a8c..3e4f760 100644
>>>> --- a/arch/x86/kvm/vmx.c
>>>> +++ b/arch/x86/kvm/vmx.c
>>>> @@ -771,8 +771,6 @@ enum segment_cache_field {
>>>> FIELD(HOST_FS_SELECTOR, host_fs_selector),
>>>> FIELD(HOST_GS_SELECTOR, host_gs_selector),
>>>> FIELD(HOST_TR_SELECTOR, host_tr_selector),
>>>> - FIELD64(IO_BITMAP_A, io_bitmap_a),
>>>> - FIELD64(IO_BITMAP_B, io_bitmap_b),
>>> These two lines should stay.
>> Jim, could you explain why these two lines should stay?
>>
>>
>> IIUC, the main concern is from nested virtualization, which still uses
>> io_bitmap_a/io_bitmap_b..
>> if so, we really need to further clean up these code, as
>>
>> CPU_BASED_USE_IO_BITMAPS is clear, and CPU_BASED_UNCOND_IO_EXITING is set
>> for both L0/L2. after new patches which I mentioned
>> in this thread.
>>
>> right?
>>
>> Alibaba Cloud
>> Quan
>>
>>
>>
prev parent reply other threads:[~2017-12-12 8:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-08 10:22 [PATCH] KVM: VMX: drop I/O permission bitmaps Quan Xu
2017-12-08 16:18 ` David Hildenbrand
2017-12-11 5:15 ` Quan Xu
2017-12-12 8:29 ` Quan Xu
2017-12-08 17:31 ` Jim Mattson
2017-12-11 5:37 ` Quan Xu
2017-12-11 18:08 ` Jim Mattson
2017-12-12 8:39 ` Quan Xu [this message]
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=ea0cb128-68c5-87f3-53b0-ad947f92fc7d@gmail.com \
--to=quan.xu0@gmail.com \
--cc=david@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox