> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, December 11, 2014 12:59 AM
>
> On 09/12/2014 03:49, Tian, Kevin wrote:
> > - Now we have XenGT/KVMGT separately maintained, and KVMGT lags
> > behind XenGT regarding to features and qualities. Likely
> From: Song, Jike
> Sent: Wednesday, December 10, 2014 2:34 PM
>
> CC Kevin.
>
>
> On 12/09/2014 05:54 PM, Jan Kiszka wrote:
> > On 2014-12-04 03:24, Jike Song wrote:
> >> Hi all,
> >>
> >> We are pleased to announce the first release of KVMGT project. KVMGT
> is
> >> the implementation of In
> From: Daniel Vetter
> Sent: Monday, December 08, 2014 6:21 PM
>
> On Mon, Dec 08, 2014 at 10:55:01AM +0100, Gerd Hoffmann wrote:
> > On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
> > > I don't know that is exactly needed, we also need to have Windows
> > > driver considered. However, I'm q
Here is some background of this KVMGT release:
- the major purpose is for early experiment of this technique in KVM, and
throw out issues about adding in-kernel device model (or mediated pass-through
framework) in KVM.
- KVMGT shares 90% code as XenGT, regarding to vGPU device model. The
only d
> From: Jan Kiszka [mailto:jan.kis...@siemens.com]
> Sent: Tuesday, September 13, 2011 3:30 PM
>
> On 2011-09-13 08:40, Tian, Kevin wrote:
> >> From: Jan Kiszka
> >> Sent: Tuesday, September 13, 2011 12:58 AM
> >>
> >> The threaded IRQ handler
> From: Jan Kiszka
> Sent: Tuesday, September 13, 2011 12:58 AM
>
> The threaded IRQ handler for MSI-X has almost nothing in common with the
> INTx/MSI handler. Move its code into a dedicated handler.
if it's desired to further go down this cleanup path, there's also no need to
register ack notif
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Tuesday, August 30, 2011 6:57 PM
>
> On 08/30/2011 04:15 AM, Tian, Kevin wrote:
> > v2 changes:
> > define exit qualification fields for APIC-Access in vmx.h
> > use apic_reg_write instead of apic_set_
v2 changes:
define exit qualification fields for APIC-Access in vmx.h
use apic_reg_write instead of apic_set_eoi, to avoid breaking tracing
add fasteoi option to allow disabling this acceleration
commit 2a66a12cb6928c962d24907e6d39b6eb9ac94b4b
Author: Kevin Tian
Date
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Monday, August 29, 2011 3:24 PM
>
> On 08/29/2011 09:09 AM, Tian, Kevin wrote:
> >
> > static int handle_apic_access(struct kvm_vcpu *vcpu)
> > {
> > + unsigned long exit_qualification = vmcs_re
> From: Marcelo Tosatti
> Sent: Tuesday, August 23, 2011 6:47 PM
>
> > >+ if (!apic->lapic_timer.tscdeadline)
> > >+ return;
> > >+
> > >+ tsc_target = kvm_x86_ops->
> > >+ guest_to_host_tsc(apic->lapic_timer.tscdeadline);
> > >+ rdtscll
Message-
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Thursday, August 25, 2011 12:39 PM
> To: Tian, Kevin
> Cc: kvm@vger.kernel.org; Nakajima, Jun
> Subject: Re: about vEOI optimization
>
> On 08/25/2011 05:24 AM, Tian, Kevin wrote:
> > >
> > > Anothe
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Wednesday, August 24, 2011 6:00 PM
>
> On 08/23/2011 11:09 AM, Tian, Kevin wrote:
> > Hi, Avi,
> >
> > Both Eddie and Marcello once suggested vEOI optimization by skipping
> > heavy-weight instruction decode,
Hi, Avi,
Both Eddie and Marcello once suggested vEOI optimization by skipping
heavy-weight instruction decode, which reduces vEOI overhead greatly:
http://www.mail-archive.com/kvm@vger.kernel.org/msg18619.html
http://www.spinics.net/lists/kvm/msg36691.html
Though virtual x2apic serves similar p
> From: ya su
> Sent: Thursday, August 11, 2011 11:57 AM
>
> When I run winxp guest on one server, copy one file about 4G will
> take a time of 40-50 min; if I run a FC14 guest, it will take about
> 2-3 min;
>
> I copy and run the winxp image on another server, it works well, take
> about 3min.
it works in my side, due to config difference. It is caused by recent
steal time feature.
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
case MSR_KVM_STEAL_TIME:
if (unlikely(!sched_info_on()))
return 1;
static inline int sched_in
> From: Alexander Graf
> Sent: Tuesday, July 05, 2011 8:42 AM
>
>
> On 05.07.2011, at 01:09, Sasha Levin wrote:
>
> > Instead of exiting quietly, print an error if the VMX or the SVM bits
> > were already set when loading the module.
> >
> > Having VMX/SVM bits set means that either there is som
> From: Sasha Levin
> Sent: Tuesday, July 05, 2011 7:09 AM
>
> Instead of exiting quietly, print an error if the VMX or the SVM bits
> were already set when loading the module.
>
> Having VMX/SVM bits set means that either there is someone else doing
> hardware virtualization, or that the BIOS is
> From: Ingo Molnar
> Sent: Monday, May 30, 2011 3:41 PM
>
>
> * Yang, Wei Y wrote:
>
> > This patch removes SMEP bit from CR4_RESERVED_BITS.
>
> I'm wondering, what is the best-practice way for tools/kvm/ to set
> SMEP for the guest kernel automatically, even if the guest kernel
> itsef has n
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Monday, May 30, 2011 6:00 PM
>
> On 05/30/2011 12:18 PM, Tian, Kevin wrote:
> > > From: Avi Kivity [mailto:a...@redhat.com]
> > > Sent: Monday, May 30, 2011 5:14 PM
> > >
> > > On 05/30/2011
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Monday, May 30, 2011 5:14 PM
>
> On 05/30/2011 12:08 PM, Tian, Kevin wrote:
> > > From: Avi Kivity
> > > Sent: Monday, May 30, 2011 4:52 PM
> > >
> > > On 05/30/2011 06:01 AM, Yang, Wei Y
> From: Avi Kivity
> Sent: Monday, May 30, 2011 4:52 PM
>
> On 05/30/2011 06:01 AM, Yang, Wei Y wrote:
> > This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
> > Protection) in KVM. SMEP prevents kernel from executing code in application.
> > Updated Intel SDM describes this C
> From: Yang, Wei Y
> Sent: Thursday, May 26, 2011 9:29 PM
>
> This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
> Protection) in KVM. SMEP prevents kernel from executing code in application.
> Updated Intel SDM describes this CPU feature. The document will be published
> soo
> From: Nadav Har'El
> Sent: Thursday, May 26, 2011 4:01 AM
>
> Hi,
>
> This is the eleventh iteration of the nested VMX patch set, and hopefully the
> last in this format.
>
> Improvements in this version over the previous one include:
>
> * Overhauled vmcs, cpu, and launched handling (new lo
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Wednesday, May 25, 2011 9:26 PM
>
> On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 18/31] nVMX:
> Implement VMLAUNCH and VMRESUME":
> > > + if (!saved_vmcs02)
> > > +
> From: Nadav Har'El
> Sent: Wednesday, May 25, 2011 9:21 PM
>
> On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 20/31] nVMX:
> Exiting from L2 to L1":
> > How about SYSENTER and PERF_GLOBAL_CTRL MSRs? At least a TODO
> comment
> &
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Wednesday, May 25, 2011 8:34 PM
>
> On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 23/31] nVMX:
> Correct handling of interrupt injection":
> > > static void enable_irq_window(stru
> From: Nadav Har'El
> Sent: Wednesday, May 25, 2011 7:55 PM
>
> On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 31/31] nVMX:
> Documentation":
> > > +On Intel processors, KVM uses Intel's VMX (Virtual-Machine eXtensions)
> > > +
> 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.
> >>
> >>
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 4:00 AM
>
> This patch includes a brief introduction to the nested vmx feature in the
> Documentation/kvm directory. The document also includes a copy of the
> vmcs12 structure, as requested by Avi Kivity.
>
> Signed-off-by: Nadav Har'El
> ---
>
> From: Nadav Har'El
> Sent: Wednesday, May 25, 2011 6:14 PM
>
> On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 25/31] nVMX:
> Correct handling of idt vectoring info":
> > Here got one question. How about L2 has interrupt exiting disabled? That
>
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:57 AM
>
> This patch adds correct handling of IDT_VECTORING_INFO_FIELD for the
> nested
> case.
>
> When a guest exits while delivering an interrupt or exception, we get this
> information in IDT_VECTORING_INFO_FIELD in the VMCS. When L2 exits
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:56 AM
>
> The code in this patch correctly emulates external-interrupt injection
> while a nested guest L2 is running.
>
> Because of this code's relative un-obviousness, I include here a longer-than-
> usual justification for what it does - mu
> From: Tian, Kevin
> Sent: Wednesday, May 25, 2011 4:40 PM
> > If L1 turns on VM_EXIT_ACK_INTR_ON_EXIT (again, no hypervisor that I know
> > does), things look very different from the description above: L1 expects
>
> Type-1 bare metal hypervisor may enable this bit,
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:56 AM
>
> The code in this patch correctly emulates external-interrupt injection
> while a nested guest L2 is running.
>
> Because of this code's relative un-obviousness, I include here a longer-than-
> usual justification for what it does - mu
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Wednesday, May 25, 2011 4:06 PM
>
> On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 20/31] nVMX:
> Exiting from L2 to L1":
> > IOW, I disagree that if L0/L1 set same bit in cr0_guest_host
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:53 AM
>
> Implement the VMLAUNCH and VMRESUME instructions, allowing a guest
> hypervisor to run its own guests.
>
> This patch does not include some of the necessary validity checks on
> vmcs12 fields before the entry. These will appear in a s
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:55 AM
>
> This patch contains the logic of whether an L2 exit should be handled by L0
> and then L2 should be resumed, or whether L1 should be run to handle this
> exit (using the nested_vmx_vmexit() function of the previous patch).
>
> The bas
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Wednesday, May 25, 2011 1:38 PM
>
> On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 21/31] nVMX:
> vmcs12 checks on nested entry":
> > > + if (vmcs12->launch_state == launch) {
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:55 AM
>
> This patch adds a bunch of tests of the validity of the vmcs12 fields,
> according to what the VMX spec and our implementation allows. If fields
> we cannot (or don't want to) honor are discovered, an entry failure is
> emulated.
>
>
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:54 AM
>
> This patch implements nested_vmx_vmexit(), called when the nested L2 guest
> exits and we want to run its L1 parent and let it handle this exit.
>
> Note that this will not necessarily be called on every L2 exit. L0 may decide
> to ha
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Tuesday, May 24, 2011 9:43 PM
>
> On Tue, May 24, 2011, Tian, Kevin wrote about "RE: [PATCH 20/31] nVMX:
> Exiting from L2 to L1":
> > > +vmcs12_guest_cr0(struct kvm_vcpu *vcpu, struct vmcs12 *vm
> 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.
>
> -
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:54 AM
>
> This patch implements nested_vmx_vmexit(), called when the nested L2 guest
> exits and we want to run its L1 parent and let it handle this exit.
>
> Note that this will not necessarily be called on every L2 exit. L0 may decide
> to ha
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Tuesday, May 24, 2011 7:37 PM
>
> On 05/24/2011 02:30 PM, Tian, Kevin wrote:
> > >
> > > We don't do that. vcpu migration calls vcpu_clear() with interrupts
> > > enabled, which then c
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Tuesday, May 24, 2011 7:27 PM
>
> On 05/24/2011 02:20 PM, Tian, Kevin wrote:
> > > I don't think it's possible. Both calls are done with interrupts
> > > disabled.
> >
> > If that's th
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Tuesday, May 24, 2011 7:06 PM
>
> On 05/24/2011 11:20 AM, Tian, Kevin wrote:
> > >
> > > The (vmx->cpu.cpu != cpu) case in __loaded_vmcs_clear should ideally
> never
> > > happen: In the cpu offli
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Tuesday, May 24, 2011 5:45 PM
>
> On Tue, May 24, 2011, Tian, Kevin wrote about "RE: [PATCH 18/31] nVMX:
> Implement VMLAUNCH and VMRESUME":
> > > + /*
> > > + * Switch from L1&#x
> From: Nadav Har'El
> Sent: Tuesday, May 24, 2011 5:19 PM
>
> On Tue, May 24, 2011, Tian, Kevin wrote about "RE: [PATCH 17/31] nVMX:
> Prepare vmcs02 from vmcs01 and vmcs12":
> > > +static inline unsigned long guest_readable_cr4(struct vmcs12 *fiel
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:53 AM
>
> Implement the VMLAUNCH and VMRESUME instructions, allowing a guest
> hypervisor to run its own guests.
>
> This patch does not include some of the necessary validity checks on
> vmcs12 fields before the entry. These will appear in a s
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Tuesday, May 24, 2011 3:57 PM
>
> On Tue, May 24, 2011, Tian, Kevin wrote about "RE: [PATCH 08/31] nVMX: Fix
> local_vcpus_link handling":
> > > +static inline void loaded_vm
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:53 AM
>
> This patch contains code to prepare the VMCS which can be used to actually
> run the L2 guest, vmcs02. prepare_vmcs02 appropriately merges the
> information
> in vmcs12 (the vmcs that L1 built for L2) and in vmcs01 (our desires for our
> From: Nadav Har'El
> Sent: Tuesday, May 24, 2011 2:51 AM
>
> > >+ vmcs_init(vmx->loaded_vmcs->vmcs);
> > >+ vmx->loaded_vmcs->cpu = -1;
> > >+ vmx->loaded_vmcs->launched = 0;
> >
> > Perhaps a loaded_vmcs_init() to encapsulate initialization of these
> > three fields, you'll probably reuse it
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Sunday, May 22, 2011 4:30 PM
>
> Hi,
>
> On Fri, May 20, 2011, Tian, Kevin wrote about "RE: [PATCH 07/31] nVMX:
> Introduce vmcs02: VMCS used to run L2":
> > Possibly we can maintain the vm
> From: Avi Kivity
> Sent: Monday, May 23, 2011 11:49 PM
> (regarding interrupts, I think we can do that work post-merge. But I'd
> like to see Kevin's comments addressed)
My earlier comment has been addressed by Nadav with his explanation.
Thanks
Kevin
--
To unsubscribe from this list: send the
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Sunday, May 22, 2011 3:23 PM
>
> Hi,
>
> On Sun, May 22, 2011, Tian, Kevin wrote about "RE: [PATCH 07/31] nVMX:
> Introduce vmcs02: VMCS used to run L2":
> > Here the vmcs02 being overrid
> From: Nadav Har'El [mailto:n...@math.technion.ac.il]
> Sent: Saturday, May 21, 2011 4:32 AM
>
> On Fri, May 20, 2011, Tian, Kevin wrote about "RE: [PATCH 07/31] nVMX:
> Introduce vmcs02: VMCS used to run L2":
> > btw, shouldn't you clear recycled VMCS a
> From: Tian, Kevin
> Sent: Friday, May 20, 2011 4:05 PM
>
> > From: Nadav Har'El
> > Sent: Tuesday, May 17, 2011 3:48 AM
> >
> > We saw in a previous patch that L1 controls its L2 guest with a vcms12.
> > L0 needs to create a real VMCS for running
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:49 AM
>
> In this patch we add to vmcs12 (the VMCS that L1 keeps for L2) all the
> standard VMCS fields.
>
> Later patches will enable L1 to read and write these fields using VMREAD/
> VMWRITE, and they will be used during a VMLAUNCH/VMRESUME i
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:48 AM
>
> We saw in a previous patch that L1 controls its L2 guest with a vcms12.
> L0 needs to create a real VMCS for running L2. We call that "vmcs02".
> A later patch will contain the code, prepare_vmcs02(), for filling the vmcs02
> fields. T
> From: Nadav Har'El
> Sent: Tuesday, May 17, 2011 3:45 AM
>
> This patch allows a guest to use the VMXON and VMXOFF instructions, and
> emulates them accordingly. Basically this amounts to checking some
> prerequisites, and then remembering whether the guest has enabled or
> disabled VMX operatio
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2008年9月28日 12:23
>
>There is no issue on the host, since all drivers operate on the same
>trust level. A misbehaving driver on the host will take down the entire
>system even without shared interrupts, by corrupting memory, not
>releasing a lock, e
>From: Dong, Eddie
>Sent: 2008年9月28日 10:04
>
>Tian, Kevin wrote:
>>> From:Avi Kivity
>>> Sent: 2008年9月27日 17:50
>>>
>>> Yang, Sheng wrote:
>>>> After check host shared interrupts situation, I got a
>>>> question here:
>
>From:Avi Kivity
>Sent: 2008年9月27日 17:50
>
>Yang, Sheng wrote:
>> After check host shared interrupts situation, I got a question here:
>>
>> If I understand correctly, current solution don't block host
>shared irq, just
>> come with the performance pentry. The penalty come with host
>disabled irq
>
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2008年7月27日 16:27
>
>Tian, Kevin wrote:
>>> From: Darrick J. Wong
>>> Sent: 2008年7月16日 7:18
>>>
>>> I envision four scenarios:
>>>
>>> 0. Guests that don't know about cpufreq
>From: Darrick J. Wong [mailto:[EMAIL PROTECTED]
>Sent: 2008年7月18日 3:05
>
>If there are multiple VMs that are busy, the busy ones will fight among
>themselves for CPU time. I still see some priority boost, just not as
>much.
some micro-level analysis is useful here.
>
>I wonder how stable the v
>From: Darrick J. Wong
>Sent: 2008年7月16日 7:18
>
>I envision four scenarios:
>
>0. Guests that don't know about cpufreq still run at whatever
>nice level
>they started with.
>
>1. If we have a system with a lot of idle VMs, they will all
>run with +5
>nice and this patch has no effect.
>
>2. If we
66 matches
Mail list logo
