QLIST_FOREACH_SAFE?
On Thu, Nov 25, 2010 at 03:06:45PM +0900, Yoshiaki Tamura wrote:
> By copying the next entry to a tmp pointer,
> qemu_del_vm_change_state_handler() can be called in the handler.
>
> Signed-off-by: Yoshiaki Tamura
> ---
> vl.c |5 +++--
> 1 files changed, 3 insertions(+),
(2010/12/08 1:45), Takuya Yoshikawa wrote:
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index f628234..d9fe35d 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -596,7 +596,9 @@ void kvm_destroy_pic(struct kvm *kvm)
struct kvm_pic *vpic = kvm->arch.vpic;
CPUID's OSXSAVE is a mirror of CR4.OSXSAVE bit. We need to update the CPUID
after migration.
Cc: sta...@kernel.org
Signed-off-by: Sheng Yang
---
arch/x86/kvm/x86.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ed373ba..51a
We found out that any client side test that has to implement
a substantial amount of code in the form of sub-tests could
benefit from having the KVM test mechanism of loading subtests
available. So in order to maximize reuse, turn the mechanism
into a class, called subtest_loader. Any client side t
> At the 2010 Linux Plumber's Conference Virtualization Mini-Conference
> earlier
> this month, I did a presentation about physical memory utilization and
> Transcendent Memory ("tmem"). I mentioned that I am developing an in-
> kernel
> version of tmem that might be suitable, with small modificat
On 12/07/2010 04:00 PM, Lok Kwong Yan wrote:
Thanks for the quick response. It is greatly appreciated.
Can you please point me in the right direction on finding out why the EPTP
(EPT_POINTER& mmu.root_hpa) have so many different values?
The table is built dynamically as memory is faulted
Thanks for the quick response. It is greatly appreciated.
Can you please point me in the right direction on finding out why the EPTP
(EPT_POINTER & mmu.root_hpa) have so many different values?
Thanks again.
From: Anthony Liguori [anth...@codemonkey.ws]
On 12/07/2010 03:47 PM, Lok Kwong Yan wrote:
After some testing and digging around the 2.6.32-26 Kernel, Ubuntu port, , it
seems to me that KVM creates a separate EPT table for each separate guest CR3
value. So, if there are 100 guest processes, there are essentially 100 EPT
tables. Is this co
After some testing and digging around the 2.6.32-26 Kernel, Ubuntu port, , it
seems to me that KVM creates a separate EPT table for each separate guest CR3
value. So, if there are 100 guest processes, there are essentially 100 EPT
tables. Is this correct? If so, can someone please tell me where
On Tue, Dec 7, 2010 at 1:22 AM, Avi Kivity wrote:
> On 12/06/2010 10:38 PM, David Sharp wrote:
>> On Sat, Dec 4, 2010 at 12:11 AM, Avi Kivity wrote:
>> > On 12/04/2010 02:13 AM, David Sharp wrote:
>> >>
>> >> Signed-off-by: David Sharp
>> >> ---
>> >> arch/x86/kvm/trace.h | 8
>>
On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote:
> On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote:
> > Usually nobody usually thinks about that scenario (me included and
> > specially),
> > but kvmclock can be actually disabled in the host.
> >
> > It happens in two scenar
Memo:
- kvm_io_bus_register_dev() was protected as far as I checked.
- kvm_create_pit() was commented like "Caller must hold slots_lock"
but kvm_free_pit() was not. So I don't know if I should protect
the whole kvm_free_pit().
What is the best fix? -- or I misread something?
Thanks,
Ta
To support xsave properly for the guest the SVM module need
software support for it. As long as this is not present do
not report the xsave as supported feature in cpuid.
As a side-effect this patch moves the bit() helper function
into the x86.h file so that it can be used in svm.c too.
Cc: sta...
This patch implements the xsetbv intercept to the AMD part
of KVM. This makes AVX usable in a save way for the guest on
AVX capable AMD hardware.
The patch is tested by using AVX in the guest and host in
parallel and checking for data corruption. I also used the
KVM xsave unit-tests and they all pa
On Tue, Dec 07, 2010 at 04:34:33AM -0500, Avi Kivity wrote:
> On 12/06/2010 07:48 PM, Roedel, Joerg wrote:
> > On Mon, Dec 06, 2010 at 11:10:46AM -0500, Avi Kivity wrote:
> > > On 12/03/2010 06:42 PM, Joerg Roedel wrote:
> > > > This patch implements the xsetbv intercept to the AMD part
> > > >
* Jes Sorensen (jes.soren...@redhat.com) wrote:
> On 12/07/10 00:51, Chris Wright wrote:
> > Please send in any agenda items you are interested in covering.
> >
> > thanks,
> > -chris
> >
>
> No agenda, no replies
>
> Call canceled I presume?
Indeed, next week, then pick up next year...
--
On 12/07/10 00:51, Chris Wright wrote:
> Please send in any agenda items you are interested in covering.
>
> thanks,
> -chris
>
No agenda, no replies
Call canceled I presume?
Jes
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.ke
On 12/07/2010 04:30 PM, Andre Przywara wrote:
Avi Kivity wrote:
On 12/07/2010 12:59 PM, Andre Przywara wrote:
Newer SVM implementations provide the GPR number in the VMCB, so
that the emulation path is no longer necesarry to handle CR
register access intercepts. Implement the handling in svm.c
Avi Kivity wrote:
On 12/07/2010 12:59 PM, Andre Przywara wrote:
Newer SVM implementations provide the GPR number in the VMCB, so
that the emulation path is no longer necesarry to handle CR
register access intercepts. Implement the handling in svm.c and
use it when the info is provided.
Signed-o
On 12/07/2010 05:59 AM, Takuya Yoshikawa wrote:
>
> Well, you can give it a name. Meanwhile I've applied patch 1, thanks.
>
How about this?
Looks good, applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscri
On 12/07/2010 12:59 PM, Andre Przywara wrote:
In case of a nested page fault or an intercepted #PF newer SVM
implementations provide a copy of the faulting instruction bytes
in the VMCB.
Use these bytes to feed the instruction emulator and avoid the costly
guest instruction fetch in this case.
On 12/07/2010 12:59 PM, Andre Przywara wrote:
When the DecodeAssist feature is available, the linear address
is provided in the VMCB on INVLPG intercepts. Use it directly to
avoid any decoding and emulation.
This is only useful for shadow paging, though.
Signed-off-by: Andre Przywara
---
arch/
On 12/07/2010 12:59 PM, Andre Przywara wrote:
Newer SVM implementations provide the GPR number in the VMCB, so
that the emulation path is no longer necesarry to handle debug
register access intercepts. Implement the handling in svm.c and
use it when the info is provided.
+static int dr_interce
On 12/07/2010 12:59 PM, Andre Przywara wrote:
Newer SVM implementations provide the GPR number in the VMCB, so
that the emulation path is no longer necesarry to handle CR
register access intercepts. Implement the handling in svm.c and
use it when the info is provided.
Signed-off-by: Andre Przywa
On 12/07/2010 01:02 PM, Alexander Graf wrote:
On 07.12.2010, at 11:59, Andre Przywara wrote:
> Newer SVM implementations provide the GPR number in the VMCB, so
> that the emulation path is no longer necesarry to handle debug
> register access intercepts. Implement the handling in svm.c and
>
On 12/07/2010 02:49 PM, Nadav Har'El wrote:
On Tue, Dec 07, 2010, Avi Kivity wrote about "Re: KVM call minutes for Nov 30":
>...
> All it requires is a
> kvm_set_cr3() which will load the PDPTEs into the PDPTRs if PAE is
> enabled. You may need to order the loading of CR0, CR3, CR4, and EFER
On Tue, Dec 07, 2010, Avi Kivity wrote about "Re: KVM call minutes for Nov 30":
>...
> All it requires is a
> kvm_set_cr3() which will load the PDPTEs into the PDPTRs if PAE is
> enabled. You may need to order the loading of CR0, CR3, CR4, and EFER
> to achieve the desired effect.
I did this m
When the DecodeAssist feature is available, the linear address
is provided in the VMCB on INVLPG intercepts. Use it directly to
avoid any decoding and emulation.
This is only useful for shadow paging, though.
Signed-off-by: Andre Przywara
---
arch/x86/kvm/svm.c |7 ++-
1 files changed, 6
Hi,
upcoming AMD CPUs will have a SVM enhancement called DecodeAssist
which will provide more information when intercepting certain events.
These information allows to skip the instruction fetching and
decoding and handle the intercept immediately.
This patch set implements all the features which
the recent APM Vol.2 and the recent AMD CPUID specification describe
new CPUID features bits for SVM. Name them here for later usage.
Signed-off-by: Andre Przywara
---
arch/x86/kvm/svm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm
In case of a nested page fault or an intercepted #PF newer SVM
implementations provide a copy of the faulting instruction bytes
in the VMCB.
Use these bytes to feed the instruction emulator and avoid the costly
guest instruction fetch in this case.
Signed-off-by: Andre Przywara
---
arch/x86/incl
On 07.12.2010, at 11:59, Andre Przywara wrote:
> Newer SVM implementations provide the GPR number in the VMCB, so
> that the emulation path is no longer necesarry to handle debug
> register access intercepts. Implement the handling in svm.c and
> use it when the info is provided.
>
> Signed-off-
Newer SVM implementations provide the GPR number in the VMCB, so
that the emulation path is no longer necesarry to handle debug
register access intercepts. Implement the handling in svm.c and
use it when the info is provided.
Signed-off-by: Andre Przywara
---
arch/x86/kvm/svm.c | 55 ++
Newer SVM implementations provide the GPR number in the VMCB, so
that the emulation path is no longer necesarry to handle CR
register access intercepts. Implement the handling in svm.c and
use it when the info is provided.
Signed-off-by: Andre Przywara
---
arch/x86/include/asm/svm.h |2 +
ar
On 12/03/2010 04:25 PM, Joerg Roedel wrote:
Hi Avi, Hi Marcelo,
here is the patch-set to add support for the Flush-By-ASID feature to
KVM on AMD. Patches 1 and 2 clean up the code a little bit and patch 3
implements the feature itself.
Applied, thanks.
--
error compiling committee.c: too many
On 12/07/2010 04:33 AM, Xiao Guangrong wrote:
It's the speculative path if 'no_apf = 1' and we will specially handle this
speculative path in the later patch, so 'prefault' is better to fit the sense
Applied all, thanks.
--
error compiling committee.c: too many arguments to function
--
To uns
On 12/03/2010 12:45 PM, Joerg Roedel wrote:
Hi Avi, Hi Marcelo,
here is a patch-set which adds support for VMCB state caching to KVM.
This is a new CPU feature where software can mark certain parts of the
VMCB as unchanged since the last vmexit and the hardware can then avoid
reloading these par
On 12/06/2010 07:48 PM, Roedel, Joerg wrote:
On Mon, Dec 06, 2010 at 11:10:46AM -0500, Avi Kivity wrote:
> On 12/03/2010 06:42 PM, Joerg Roedel wrote:
> > This patch implements the xsetbv intercept to the AMD part
> > of KVM. This makes AVX usable in a save way for the guest on
> > AVX cap
On 12/06/2010 10:38 PM, David Sharp wrote:
On Sat, Dec 4, 2010 at 12:11 AM, Avi Kivity wrote:
> On 12/04/2010 02:13 AM, David Sharp wrote:
>>
>> Signed-off-by: David Sharp
>> ---
>>arch/x86/kvm/trace.h |8
>>1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --gi
On 12/06/2010 09:39 PM, Nadav Har'El wrote:
On Wed, Dec 01, 2010, Nadav Har'El wrote about "Re: KVM call minutes for Nov
30":
> Specifically, in the last review I was asked to make sure that shadow-on-EPT
> works so that users do not need to remember to add the "ept=0" module option
> on L0.
On Mon, Dec 06, 2010 at 05:49:55PM -0200, Marcelo Tosatti wrote:
> On Fri, Dec 03, 2010 at 11:45:47AM +0100, Joerg Roedel wrote:
> > Hi Avi, Hi Marcelo,
> >
> > here is a patch-set which adds support for VMCB state caching to KVM.
> > This is a new CPU feature where software can mark certain parts
On Mon, Dec 06, 2010 at 05:29:24PM -0200, Marcelo Tosatti wrote:
> On Fri, Dec 03, 2010 at 11:45:52AM +0100, Joerg Roedel wrote:
> > This patch implements the clean-bit for all interrupt
> > related state in the vmcb. This corresponds to vmcb offset
> > 0x60-0x67.
> >
> > Signed-off-by: Joerg Roed
42 matches
Mail list logo
