2017-12-07 10:33+0800, Quan Xu:
>
>
> On 2017/12/07 02:19, Jim Mattson wrote:
> > On Wed, Dec 6, 2017 at 3:17 AM, Quan Xu <quan.xu0@xxxxxxxxx> wrote:
> > >
> > > On 2017/12/06 05:26, Radim Krčmář wrote:
> > > > 2017-12-01 10:21-0800, Jim Mattson:
> > > > > Since we no longer allow any I/O ports to be passed through to the guest,
> > > > > we can use the same page for I/O bitmap A and I/O bitmap B.
> > > > I think we can disable the feature and save the second page as well:
> > > >
> > > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > > index e25c55ea2eb7..80859a7cdf6d 100644
> > > > --- a/arch/x86/kvm/vmx.c
> > > > +++ b/arch/x86/kvm/vmx.c
> > > > @@ -3624,7 +3624,7 @@ static __init int setup_vmcs_config(struct
> > > > vmcs_config *vmcs_conf)
> > > > #endif
> > > > CPU_BASED_CR3_LOAD_EXITING |
> > > > CPU_BASED_CR3_STORE_EXITING |
> > > > - CPU_BASED_USE_IO_BITMAPS |
> > > > + CPU_BASED_UNCOND_IO_EXITING |
> > > > CPU_BASED_MOV_DR_EXITING |
> > > > CPU_BASED_USE_TSC_OFFSETING |
> > > > CPU_BASED_INVLPG_EXITING |
> > > >
> > > Jim / Radim,
> > >
> > >
> > > As a logical processor uses these bitmaps if and only if the “use I/O
> > > bitmaps” control is 1.
> > >
> > > Since we drop 'CPU_BASED_USE_IOBITMAPS' in vmcs configuration.. We could
> > > also drop
> > > 'IO_BITMAP_A'/'IO_BITMAP_B'/'vmx_io_bitmap_a'/'vmx_io_bitmap_b' for a
> > > furthermore
> > > cleanup as below:
> > >
> > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > index 04b4dbc..3e4f760 100644
> > > --- a/arch/x86/kvm/vmx.c
> > > +++ b/arch/x86/kvm/vmx.c
> > > @@ -771,8 +771,6 @@ static struct pi_desc *vcpu_to_pi_desc(struct kvm_vcpu
> > > *vcpu)
> > > 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),
> > Stet.
> >
> > > FIELD64(MSR_BITMAP, msr_bitmap),
> > > FIELD64(VM_EXIT_MSR_STORE_ADDR, vm_exit_msr_store_addr),
> > > FIELD64(VM_EXIT_MSR_LOAD_ADDR, vm_exit_msr_load_addr),
> > > @@ -943,8 +941,6 @@ static bool nested_vmx_is_page_fault_vmexit(struct
> > > vmcs12 *vmcs12,
> > > static DEFINE_PER_CPU(spinlock_t, blocked_vcpu_on_cpu_lock);
> > >
> > > enum {
> > > - VMX_IO_BITMAP_A,
> > > - VMX_IO_BITMAP_B,
> > > VMX_MSR_BITMAP_LEGACY,
> > > VMX_MSR_BITMAP_LONGMODE,
> > > VMX_MSR_BITMAP_LEGACY_X2APIC_APICV,
> > > @@ -958,8 +954,6 @@ enum {
> > >
> > > static unsigned long *vmx_bitmap[VMX_BITMAP_NR];
> > >
> > > -#define vmx_io_bitmap_a (vmx_bitmap[VMX_IO_BITMAP_A])
> > > -#define vmx_io_bitmap_b (vmx_bitmap[VMX_IO_BITMAP_B])
> > > #define vmx_msr_bitmap_legacy (vmx_bitmap[VMX_MSR_BITMAP_LEGACY])
> > > #define vmx_msr_bitmap_longmode (vmx_bitmap[VMX_MSR_BITMAP_LONGMODE])
> > > #define vmx_msr_bitmap_legacy_x2apic_apicv
> > > (vmx_bitmap[VMX_MSR_BITMAP_LEGACY_X2APIC_APICV])
> > > @@ -3632,7 +3626,7 @@ static __init int setup_vmcs_config(struct vmcs_config
> > > *vmcs_conf)
> > > #endif
> > > CPU_BASED_CR3_LOAD_EXITING |
> > > CPU_BASED_CR3_STORE_EXITING |
> > > - CPU_BASED_USE_IO_BITMAPS |
> > > + CPU_BASED_UNCOND_IO_EXITING |
> > Is it safe to assume that all CPUs (both physical and virtual)
> > currently running kvm will support this control bit?
>
> Jim, I don't see some conditions to "Use I/O bitmaps" or "Unconditional I/O
> exiting" in Intel SDM.
> and in prepare_vmcs02(),
>
> ...
> /*
> * Merging of IO bitmap not currently supported.
> * Rather, exit every time.
> */
> exec_control &= ~CPU_BASED_USE_IO_BITMAPS;
> exec_control |= CPU_BASED_UNCOND_IO_EXITING;
> ...
>
>
> So I think it is safe for cpu and vcpu.
I agree that it is safe.
>
> as sdm said, """ "Unconditional I/O exiting" -- This control determines
> whether executions of I/O
> instructions (IN, INS/INSB/INSW/INSD, OUT, and OUTS/OUTSB/OUTSW/OUTSD) cause
> VM exits.
> "Use I/O bitmaps" -- For this control, “0” means “do not use I/O bitmaps”
> and “1” means
> “use I/O bitmaps.” """"
>
> I think it is safe for all CPU, if we clear the "Use I/O bitmaps". It
> doesn't matter whether
> the "Unconditional I/O exiting" is set or clear.. Of Course both bits are
> clear, which may
> make host/guest to the incorrect field.
>
> is it? Radim, could you help me double check it?
I don't think it is correct to have neither, though, SMD describes them
as an alternative:
33.3.2.1 PIC Virtualization
If the VMM is not supporting direct access to any I/O ports from a
guest, it can set the unconditional-I/O-exiting in the VM-execution
control field instead of activating I/O bitmaps.
And a quick test shows that we get a VM entry failure if both of them
are clear, although I can't find that explicitly in SDM.
Thanks.
