On Tue, 2012-08-28 at 17:10 +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, August 28, 2012 9:27 PM
To: Bhushan Bharat-R65777
Cc: kvm@vger.kernel.org; Avi Kivity; qemu-de...@nongnu.org
Subject:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, August 29, 2012 12:16 PM
To: Bhushan Bharat-R65777
Cc: kvm@vger.kernel.org; Avi Kivity; qemu-de...@nongnu.org
Subject: Re: Isuue assiging devices using VFIO on x86
On Tue, 2012-08-28 at
On 08/28/2012 07:54 PM, Paolo Bonzini wrote:
From: Jason Wangjasow...@redhat.com
Instead of storing the queue index in transport-specific virtio structs,
this patch moves them to vring_virtqueue and introduces an helper to get
the value. This lets drivers simplify their management and tracing
Anthony Liguori anth...@codemonkey.ws writes:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
Hi all,
I have been testing network throughput and latency and I was wondering
if my measurements are as expected.
For the test, I used Fedora 17 for both host and guest, using kernel
3.5.2-3.fc17.86_64.
Pinging an external server on the LAN from the host, using a gigabit
interface, the
On 2012-08-28 23:49, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 01:02:26PM +0200, Jan Kiszka wrote:
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is being maintained
in qemu-kvm for several years and is
On 2012-08-28 23:26, Peter Maydell wrote:
On 27 August 2012 13:15, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-27 14:07, Andreas Färber wrote:
Am I correct to understand we compile this only for i386 / x86_64?
This is correct.
Did we ever make a decision about whether architecture
On 29 August 2012 09:47, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-28 23:26, Peter Maydell wrote:
Since this is arch-specific we should probably give the
resulting device a more specific name than pci-assign,
which implies that it is (a) ok for any PCI system and
(b) not something
On 2012-08-29 10:49, Peter Maydell wrote:
On 29 August 2012 09:47, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-28 23:26, Peter Maydell wrote:
Since this is arch-specific we should probably give the
resulting device a more specific name than pci-assign,
which implies that it is (a) ok
On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 07:02:42PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
On Tue, Aug 28, 2012
On Wed, Aug 29, 2012 at 06:59:03AM -0300, Marcelo Tosatti wrote:
I don't understand. What is the problem with the proposal?
What will not work with our protocol?
Can you give an example please?
Too late for 1.2?
Absolutely (in my opinion).
My concern here is that you are
On Tue, Aug 28, 2012 at 08:50:09PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 01:25:35AM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 07:02:42PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012
On Wed, Aug 29, 2012 at 06:59:03AM -0300, Marcelo Tosatti wrote:
On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 07:02:42PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012
On Wed, Aug 29, 2012 at 01:23:24PM +0300, Michael S. Tsirkin wrote:
Michael, not migrating the PVEOI MSR actually crashes the guest?
Not at all. migration currently simply disables PV EOI, so
each EOI triggers exits after migration.
I would like to add: without this patch guest will
On Wed, Aug 29, 2012 at 07:03:34AM -0300, Marcelo Tosatti wrote:
On Wed, Aug 29, 2012 at 06:59:03AM -0300, Marcelo Tosatti wrote:
I don't understand. What is the problem with the proposal?
What will not work with our protocol?
Can you give an example please?
Too late for
On Wed, Aug 29, 2012 at 10:44:38AM +0200, Jan Kiszka wrote:
On 2012-08-28 23:49, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 01:02:26PM +0200, Jan Kiszka wrote:
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is
From: Wang Sen senw...@linux.vnet.ibm.com
On a 32-bit guest with virtio-scsi devices and more than 1G physical memory,
QEMU may crash or Linux will fail to boot.
This bug happens when building the sg_list that is eventually put in the
virtqueue.
Each buffer from the original sg_list is added
virtio-scsi needs to report LUNs greater than 256 using the flat
format. Because the Linux SCSI layer just maps the SCSI LUN to
an u32, without any parsing, these end up in the range from 16640
to 32767. Fix max_lun to account for the possibility that logical
unit numbers are encoded with the
On Tue, Aug 28, 2012 at 03:35:00PM +0200, Sasha Levin wrote:
On 08/28/2012 03:20 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use indirect descriptors and allocate them using a simple
Broken by commit e21f28b497.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/kvm/pci-assign.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 9cce02c..fea05b4 100644
--- a/hw/kvm/pci-assign.c
+++
Hi All,
This is KVM upstream test result against kvm.git next branch and qemu-kvm.git
master branch.
kvm.git next branch: a81aba14dc0ea499f4c218b5db0303b2ea8151d3 based on
kernel 3.6.0-rc3
qemu-kvm.git master branch: 47d70a2bcd70994d398cfb696c19ee1851e9f0ca
We filed 2 new
On 08/29/2012 07:18 AM, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not
On Wed, Aug 29, 2012 at 01:06:32PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 08:50:09PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 01:25:35AM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28,
On Wed, Aug 29, 2012 at 01:27:52PM +0200, Jan Kiszka wrote:
Broken by commit e21f28b497.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/kvm/pci-assign.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index
On Wed, Aug 29, 2012 at 09:56:12AM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 01:06:32PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 08:50:09PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 01:25:35AM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
Enable for 1.1
-M pc-1.1 -cpu
On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled
On Wed, Aug 29, 2012 at 04:18:12PM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012 at 09:56:12AM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 01:06:32PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 08:50:09PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012
On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled
Am 28.08.2012 14:57, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to
Gleb Natapov g...@redhat.com writes:
On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
On Wed, Aug 29, 2012 at 10:49:04AM -0300, Eduardo Habkost wrote:
Normally CPUID will tell you if such important MSR is available.
So we can check that at destination.
How can qemu check it, if when the qemu code was written when the MSR
didn't even exist yet?
(You could add an interface
On Wed, Aug 29, 2012 at 05:11:12PM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012 at 10:49:04AM -0300, Eduardo Habkost wrote:
Normally CPUID will tell you if such important MSR is available.
So we can check that at destination.
How can qemu check it, if when the qemu code was
https://bugzilla.kernel.org/show_bug.cgi?id=43501
Alan a...@lxorguk.ukuu.org.uk changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Aug 29, 2012 at 09:09:16AM -0500, Anthony Liguori wrote:
Gleb Natapov g...@redhat.com writes:
On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
On Wed, Aug 29, 2012 at 09:09:16AM -0500, Anthony Liguori wrote:
Gleb Natapov g...@redhat.com writes:
On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID
Michael S. Tsirkin m...@redhat.com writes:
In preparation to adding PV EOI migration for 1.2,
trivially refactor some some compat code
to make it easier to add version specific
cpuid tweaks.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
How I'd like to do this for 1.3 is to have CPU's
https://bugzilla.kernel.org/show_bug.cgi?id=42782
Tango ta...@thetangos.com changed:
What|Removed |Added
CC||ta...@thetangos.com
---
On 08/29/2012 01:07 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:35:00PM +0200, Sasha Levin wrote:
On 08/28/2012 03:20 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use
We can't simply expose the GET_SUPPORTED_CPUID results directly to the
guest, or the resulting guest-visible CPUID bits may change under the
guest's feet when we live-migrate.
We still have to implement proper per-machine-type migration
compatibility bits, but this at least is a workaround for
On Wed, Aug 29, 2012 at 12:04:25PM -0300, Eduardo Habkost wrote:
We can't simply expose the GET_SUPPORTED_CPUID results directly to the
guest, or the resulting guest-visible CPUID bits may change under the
guest's feet when we live-migrate.
We still have to implement proper per-machine-type
On Tue, Aug 28, 2012 at 4:46 PM, Rusty Russell rusty.russ...@linaro.org wrote:
Instead of overloading x86's KVM_GET_MSRS/KVM_SET_MSRS. The only basic
difference is that the ids are 64 bit.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
diff --git a/arch/arm/include/asm/kvm.h
On Wed, Aug 29, 2012 at 05:03:03PM +0200, Sasha Levin wrote:
On 08/29/2012 01:07 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:35:00PM +0200, Sasha Levin wrote:
On 08/28/2012 03:20 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
On Tue, Aug 28, 2012 at 4:47 PM, Rusty Russell rusty.russ...@linaro.org wrote:
This is a generic interface to find out what you can use
KVM_GET_ONE_REG/KVM_SET_ONE_REG on. Arhs need to define
KVM_HAVE_REG_LIST and then kvm_arch_num_regs() and
kvm_arch_copy_reg_indices() functions.
It's
On Wed, 2012-08-29 at 07:11 +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, August 29, 2012 12:16 PM
To: Bhushan Bharat-R65777
Cc: kvm@vger.kernel.org; Avi Kivity; qemu-de...@nongnu.org
Subject:
On Tue, Aug 28, 2012 at 4:47 PM, Rusty Russell rusty.russ...@linaro.org wrote:
This trivially replaces the arm-specific KVM_VCPU_GET_MSR_INDEX_LIST.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 209b432..b607f60 100644
---
On Tue, Aug 28, 2012 at 4:48 PM, Rusty Russell rusty.russ...@linaro.org wrote:
No structures at all any more.
I fail to see the great benefit of all this. The code is certainly
not easier to read and it's certainly not more clear what is going on.
Is this simply so we don't have to copy
On 29 August 2012 00:48, Rusty Russell rusty.russ...@linaro.org wrote:
No structures at all any more.
I'm not fussed whether we use structs for the core regs or
not; they're not exactly going to change in future so it's
purely a question of whether you think it's aesthetically
prettier to have
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use indirect descriptors and allocate them using a simple
kmalloc().
This patch adds a cache which will allow indirect buffers under
a configurable size to be allocated
On Wed, Aug 29, 2012 at 05:03:03PM +0200, Sasha Levin wrote:
On 08/29/2012 01:07 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:35:00PM +0200, Sasha Levin wrote:
On 08/28/2012 03:20 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
On Wed, Aug 29, 2012 at 06:10:04PM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012 at 12:04:25PM -0300, Eduardo Habkost wrote:
We can't simply expose the GET_SUPPORTED_CPUID results directly to the
guest, or the resulting guest-visible CPUID bits may change under the
guest's feet when
On 29 August 2012 00:37, Rusty Russell rusty.russ...@linaro.org wrote:
This compiles, completely untested, but it's my attempt to give
Avi (and Alexander) what he asked for in a generic register accessor.
Mingled in these patches is the conversion of the latest KVM ARM code,
which is
On 08/29/2012 05:38 PM, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012 at 05:03:03PM +0200, Sasha Levin wrote:
On 08/29/2012 01:07 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:35:00PM +0200, Sasha Levin wrote:
On 08/28/2012 03:20 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012
On 08/29/2012 05:38 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use indirect descriptors and allocate them using a simple
kmalloc().
This patch adds a cache which will allow indirect
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, August 29, 2012 8:44 PM
To: Bhushan Bharat-R65777
Cc: kvm@vger.kernel.org; Avi Kivity; qemu-de...@nongnu.org
Subject: Re: Isuue assiging devices using VFIO on x86
On Wed, 2012-08-29 at
On Wed, Aug 29, 2012 at 07:14:01PM +0200, Sasha Levin wrote:
On 08/29/2012 05:38 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use indirect descriptors and allocate them using a simple
Peter Maydell peter.mayd...@linaro.org writes:
On 29 August 2012 00:48, Rusty Russell rusty.russ...@linaro.org wrote:
No structures at all any more.
I'm not fussed whether we use structs for the core regs or
not; they're not exactly going to change in future so it's
purely a question of
Rusty Russell rusty.russ...@linaro.org writes:
No structures at all any more.
Note: the encoding of general registers makes sense, but it's not
completely logical so the code is quite messy. It would actually be
far neater to expose the struct kvm_vcpu_regs, and use offsets into
that as the
Andreas Färber afaer...@suse.de writes:
Am 28.08.2012 14:57, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
Peter Maydell peter.mayd...@linaro.org writes:
On 29 August 2012 00:37, Rusty Russell rusty.russ...@linaro.org wrote:
This compiles, completely untested, but it's my attempt to give
Avi (and Alexander) what he asked for in a generic register accessor.
Mingled in these patches is the
On Wed, 2012-08-29 at 18:42 +, Bhushan Bharat-R65777 wrote:
PFA file which have full dmeg and lspci of assigned device
On Aug 29, 2012 11:03 AM, Bhushan Bharat-R65777
r65...@freescale.commailto:r65...@freescale.com wrote:
Guestlspci
00:00.0 Host bridge: Intel Corporation 440FX -
On Tue, Aug 28, 2012 at 06:57:56PM +0900, Takuya Yoshikawa wrote:
On Mon, 27 Aug 2012 17:25:42 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Fri, Aug 24, 2012 at 06:15:49PM +0900, Takuya Yoshikawa wrote:
Although returning -1 should be likely according to the likely(),
the ASSERT
The idea of starting from next vcpu (source of yield_to + 1) seem to work
well for overcomitted guest rather than using last boosted vcpu. We can also
remove per VM variable with this approach.
Iteration for eligible candidate after this patch starts from vcpu source+1
and ends at source-1
On 08/29/2012 08:12 PM, Michael S. Tsirkin wrote:
What is a good default for net? I guess max sg?
I think that it depends on the workload. I'd say we should keep the
default to 0
(disabled) unless we can have a good way to adjust it to the load.
For *all* drivers?
Then it is
On Wed, Aug 29, 2012 at 04:10:57PM -0300, Marcelo Tosatti wrote:
On Tue, Aug 28, 2012 at 06:57:56PM +0900, Takuya Yoshikawa wrote:
On Mon, 27 Aug 2012 17:25:42 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Fri, Aug 24, 2012 at 06:15:49PM +0900, Takuya Yoshikawa wrote:
Although
On Wed, Aug 29, 2012 at 10:46:19PM +0200, Sasha Levin wrote:
On 08/29/2012 08:12 PM, Michael S. Tsirkin wrote:
What is a good default for net? I guess max sg?
I think that it depends on the workload. I'd say we should keep the
default to 0
(disabled) unless we can have a good
Hi Avi, Marcelo
this patch series implements a few micro optimizations for the x86 KVM
code base. The two major changes are constification of variables and an
optimization for the SSE emulation. The former gives the compiler more
opportunities for optimizations and ensures the r/o data is not put
Some fields can be constified and/or made static to reduce code and data
size.
Numbers for a 32 bit build:
textdata bss dec hex filename
before: 3351 80 03431 d67 cpuid.o
after: 3391 0 03391 d3f cpuid.o
Signed-off-by: Mathias
The opcode tables never change at runtime, therefor mark them const.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/kvm/emulate.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kvm/emulate.c
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/kvm/lapic.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 18d149d..07ad628 100644
--- a/arch/x86/kvm/lapic.c
+++
We never modify direct_access_msrs[], msrpm_ranges[],
svm_exit_handlers[] or x86_intercept_map[] at runtime.
Mark them r/o.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c |8
1 file changed, 4 insertions(+), 4
We use vmcs_field_to_offset_table[], kvm_vmx_segment_fields[] and
kvm_vmx_exit_handlers[] as lookup tables only -- make them r/o.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/kvm/vmx.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
As the the compiler ensures that the memory operand is always aligned
to a 16 byte memory location, use the aligned variant of MOVDQ for
read_sse_reg() and write_sse_reg().
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/kvm/emulate.c | 64
We never change emulate_ops[] at runtime so it should be r/o.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/include/asm/kvm_emulate.h |2 +-
arch/x86/kvm/emulate.c | 22 +++---
arch/x86/kvm/x86.c |2 +-
3 files changed, 13
We never change those, make them r/o.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/kvm/x86.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f8b0148..79ac03c 100644
--- a/arch/x86/kvm/x86.c
+++
On Thu, 30 Aug 2012 01:51:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
This text:
+ if (likely(!word_offset !word[0]))
+ return -1;
is a left-over from the original implementation.
There we did a ton of gratitious calls to interrupt
injection so it was important
At 08/29/2012 07:56 PM, Sasha Levin Wrote:
On 08/29/2012 07:18 AM, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the
78 matches
Mail list logo
