RE: [PATCH] new version of loaded_vmcs patch
> From: Avi Kivity > Sent: Tuesday, May 24, 2011 9:57 PM > > On 05/24/2011 04:14 PM, Avi Kivity wrote: > > On 05/24/2011 03:26 PM, Nadav Har'El wrote: > >> Hi Avi, here is a updated version of the loaded_vmcs patch which you > >> asked me > >> to send before the rest of the nvmx patches. > >> > >> Please let me know when you'd like me to send you an updated version of > >> the rest of the patches. > > > > Do you have a list of unresolved issues? > > > > If not, please repost the series. > > > > btw, since Kevin is now plowing through the patchset, please wait for > the rest of his review. > I have finished my current round of review of nVMX-v10 with all comments sent out. Thanks Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] new version of loaded_vmcs patch
On Tue, May 24, 2011 at 05:10:56PM +0300, Nadav Har'El wrote: > On Tue, May 24, 2011, Avi Kivity wrote about "Re: [PATCH] new version of > loaded_vmcs patch": > > btw, since Kevin is now plowing through the patchset, please wait for > > the rest of his review. > > Ok, I will, but note that I'll also be here after the merge, and will continue > to explain the code to Kevin and others - and to modify the code - afterwards. > > With nvmx in the tree, other people will also be able to directly modify it > themselves - if they feel strongly about some issue that I don't. > Like event handling? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] new version of loaded_vmcs patch
On 05/24/2011 05:10 PM, Nadav Har'El wrote: On Tue, May 24, 2011, Avi Kivity wrote about "Re: [PATCH] new version of loaded_vmcs patch": > btw, since Kevin is now plowing through the patchset, please wait for > the rest of his review. Ok, I will, but note that I'll also be here after the merge, and will continue to explain the code to Kevin and others - and to modify the code - afterwards. Certainly. With nvmx in the tree, other people will also be able to directly modify it themselves - if they feel strongly about some issue that I don't. Sure. I'll still ask you to review those changes, of course. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] new version of loaded_vmcs patch
On Tue, May 24, 2011, Avi Kivity wrote about "Re: [PATCH] new version of
loaded_vmcs patch":
> btw, since Kevin is now plowing through the patchset, please wait for
> the rest of his review.
Ok, I will, but note that I'll also be here after the merge, and will continue
to explain the code to Kevin and others - and to modify the code - afterwards.
With nvmx in the tree, other people will also be able to directly modify it
themselves - if they feel strongly about some issue that I don't.
--
Nadav Har'El| Tuesday, May 24 2011, 20 Iyyar 5771
n...@math.technion.ac.il |-
Phone +972-523-790466, ICQ 13349191 |:(){ :|:&};: # DANGER: DO NOT run this,
http://nadav.harel.org.il |unless you REALLY know what you're doing!
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] new version of loaded_vmcs patch
On 05/24/2011 04:14 PM, Avi Kivity wrote: On 05/24/2011 03:26 PM, Nadav Har'El wrote: Hi Avi, here is a updated version of the loaded_vmcs patch which you asked me to send before the rest of the nvmx patches. Please let me know when you'd like me to send you an updated version of the rest of the patches. Do you have a list of unresolved issues? If not, please repost the series. btw, since Kevin is now plowing through the patchset, please wait for the rest of his review. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] new version of loaded_vmcs patch
On 05/24/2011 03:26 PM, Nadav Har'El wrote: Hi Avi, here is a updated version of the loaded_vmcs patch which you asked me to send before the rest of the nvmx patches. Please let me know when you'd like me to send you an updated version of the rest of the patches. Subject: [PATCH 01/31] nVMX: Keep list of loaded VMCSs, instead of vcpus. In VMX, before we bring down a CPU we must VMCLEAR all VMCSs loaded on it because (at least in theory) the processor might not have written all of its content back to memory. Since a patch from June 26, 2008, this is done using a per-cpu "vcpus_on_cpu" linked list of vcpus loaded on each CPU. The problem is that with nested VMX, we no longer have the concept of a vcpu being loaded on a cpu: A vcpu has multiple VMCSs (one for L1, a pool for L2s), and each of those may be have been last loaded on a different cpu. So instead of linking the vcpus, we link the VMCSs, using a new structure loaded_vmcs. This structure contains the VMCS, and the information pertaining to its loading on a specific cpu (namely, the cpu number, and whether it was already launched on this cpu once). In nested we will also use the same structure to hold L2 VMCSs, and vmx->loaded_vmcs is a pointer to the currently active VMCS. Applied, thanks. Do you have a list of unresolved issues? If not, please repost the series. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] new version of loaded_vmcs patch
> From: Nadav Har'El
> Sent: Tuesday, May 24, 2011 8:26 PM
>
> Hi Avi, here is a updated version of the loaded_vmcs patch which you asked me
> to send before the rest of the nvmx patches.
>
> Please let me know when you'd like me to send you an updated version of
> the rest of the patches.
>
>
> Subject: [PATCH 01/31] nVMX: Keep list of loaded VMCSs, instead of vcpus.
>
> In VMX, before we bring down a CPU we must VMCLEAR all VMCSs loaded on it
> because (at least in theory) the processor might not have written all of its
> content back to memory. Since a patch from June 26, 2008, this is done using
> a per-cpu "vcpus_on_cpu" linked list of vcpus loaded on each CPU.
>
> The problem is that with nested VMX, we no longer have the concept of a
> vcpu being loaded on a cpu: A vcpu has multiple VMCSs (one for L1, a pool for
> L2s), and each of those may be have been last loaded on a different cpu.
>
> So instead of linking the vcpus, we link the VMCSs, using a new structure
> loaded_vmcs. This structure contains the VMCS, and the information
> pertaining
> to its loading on a specific cpu (namely, the cpu number, and whether it
> was already launched on this cpu once). In nested we will also use the same
> structure to hold L2 VMCSs, and vmx->loaded_vmcs is a pointer to the
> currently active VMCS.
>
> Signed-off-by: Nadav Har'El
Acked-by: Kevin Tian
Thanks
Kevin
> ---
> arch/x86/kvm/vmx.c | 150 ---
> 1 file changed, 86 insertions(+), 64 deletions(-)
>
> --- .before/arch/x86/kvm/vmx.c2011-05-24 15:12:22.0 +0300
> +++ .after/arch/x86/kvm/vmx.c 2011-05-24 15:12:22.0 +0300
> @@ -116,6 +116,18 @@ struct vmcs {
> char data[0];
> };
>
> +/*
> + * Track a VMCS that may be loaded on a certain CPU. If it is (cpu!=-1), also
> + * remember whether it was VMLAUNCHed, and maintain a linked list of all
> VMCSs
> + * loaded on this CPU (so we can clear them if the CPU goes down).
> + */
> +struct loaded_vmcs {
> + struct vmcs *vmcs;
> + int cpu;
> + int launched;
> + struct list_head loaded_vmcss_on_cpu_link;
> +};
> +
> struct shared_msr_entry {
> unsigned index;
> u64 data;
> @@ -124,9 +136,7 @@ struct shared_msr_entry {
>
> struct vcpu_vmx {
> struct kvm_vcpu vcpu;
> - struct list_head local_vcpus_link;
> unsigned long host_rsp;
> - int launched;
> u8fail;
> u8cpl;
> bool nmi_known_unmasked;
> @@ -140,7 +150,14 @@ struct vcpu_vmx {
> u64 msr_host_kernel_gs_base;
> u64 msr_guest_kernel_gs_base;
> #endif
> - struct vmcs *vmcs;
> + /*
> + * loaded_vmcs points to the VMCS currently used in this vcpu. For a
> + * non-nested (L1) guest, it always points to vmcs01. For a nested
> + * guest (L2), it points to a different VMCS.
> + */
> + struct loaded_vmcsvmcs01;
> + struct loaded_vmcs *loaded_vmcs;
> + bool __launched; /* temporary, used in
> vmx_vcpu_run */
> struct msr_autoload {
> unsigned nr;
> struct vmx_msr_entry guest[NR_AUTOLOAD_MSRS];
> @@ -200,7 +217,11 @@ static int vmx_set_tss_addr(struct kvm *
>
> static DEFINE_PER_CPU(struct vmcs *, vmxarea);
> static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
> -static DEFINE_PER_CPU(struct list_head, vcpus_on_cpu);
> +/*
> + * We maintain a per-CPU linked-list of VMCS loaded on that CPU. This is
> needed
> + * when a CPU is brought down, and we need to VMCLEAR all VMCSs loaded
> on it.
> + */
> +static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
> static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
>
> static unsigned long *vmx_io_bitmap_a;
> @@ -501,6 +522,13 @@ static void vmcs_clear(struct vmcs *vmcs
> vmcs, phys_addr);
> }
>
> +static inline void loaded_vmcs_init(struct loaded_vmcs *loaded_vmcs)
> +{
> + vmcs_clear(loaded_vmcs->vmcs);
> + loaded_vmcs->cpu = -1;
> + loaded_vmcs->launched = 0;
> +}
> +
> static void vmcs_load(struct vmcs *vmcs)
> {
> u64 phys_addr = __pa(vmcs);
> @@ -514,25 +542,24 @@ static void vmcs_load(struct vmcs *vmcs)
> vmcs, phys_addr);
> }
>
> -static void __vcpu_clear(void *arg)
> +static void __loaded_vmcs_clear(void *arg)
> {
> - struct vcpu_vmx *vmx = arg;
> + struct loaded_vmcs *loaded_vmcs = arg;
> int cpu = raw_smp_processor_id();
>
> - if (vmx->vcpu.cpu == cpu)
> - vmcs_clear(vmx->vmcs);
> - if (per_cpu(current_vmcs, cpu) == vmx->vmcs)
> + if (loaded_vmcs->cpu != cpu)
> + return; /* vcpu migration can race with cpu offline */
> + if (per_cpu(current_vmcs, cpu) == loaded_vmcs->vmcs)
> per_cpu(current_vmcs, cpu) = NULL;
> -
