On Wed, Dec 05, 2012 at 08:39:26PM +, Ben Hutchings wrote:
On Mon, 2012-12-03 at 12:58 +0200, Michael S. Tsirkin wrote:
Add RFS support to virtio network device.
Add a new feature flag VIRTIO_NET_F_RFS for this feature, a new
configuration field max_virtqueue_pairs to detect supported
Sound works badly with hda.
There is a slight improvement with Pulseaudio in the host;
the solution, however, is to use ALSA with AC97.
Since qemu-kvm 1.1, ac97 emulation has been reworked
and now works with Windows 7 x64.
The windows update mechanism will install the drivers
automatically,
On Wed, Dec 05, 2012 at 08:38:59PM -0200, Marcelo Tosatti wrote:
On Wed, Dec 05, 2012 at 01:14:38PM +0200, Gleb Natapov wrote:
On Wed, Dec 05, 2012 at 03:43:41AM +, Zhang, Yang Z wrote:
@@ -5657,12 +5673,20 @@ static int vcpu_enter_guest(struct kvm_vcpu
*vcpu)
}
Can you regenerate against current queue branch in
git://git.kernel.org/pub/scm/virt/kvm/kvm.git please?
On Wed, Dec 05, 2012 at 03:58:50PM +0800, Zhang Yanfei wrote:
Currently, kdump just makes all the logical processors leave VMX operation by
executing VMXOFF instruction, so any VMCSs active
Gleb Natapov wrote on 2012-12-06:
On Wed, Dec 05, 2012 at 08:38:59PM -0200, Marcelo Tosatti wrote:
On Wed, Dec 05, 2012 at 01:14:38PM +0200, Gleb Natapov wrote:
On Wed, Dec 05, 2012 at 03:43:41AM +, Zhang, Yang Z wrote:
@@ -5657,12 +5673,20 @@ static int vcpu_enter_guest(struct kvm_vcpu
On Wed, Sep 05, 2012 at 08:33:35PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 30, 2012 at 05:38:35PM +0300, Michael S. Tsirkin wrote:
The following makes 'x86info -r' dump hypervisor leaf cpu ids
(for kvm this is signature+features) when running in a vm.
On the guest we see the
On Sun, Dec 02, 2012 at 09:33:53AM +0800, Asias He wrote:
diff --git a/drivers/vhost/Kconfig.blk b/drivers/vhost/Kconfig.blk
new file mode 100644
index 000..ff8ab76
--- /dev/null
+++ b/drivers/vhost/Kconfig.blk
@@ -0,0 +1,10 @@
+config VHOST_BLK
+ tristate Host kernel accelerator
On Thu, Dec 06, 2012 at 01:41:12PM +0200, Michael S. Tsirkin wrote:
On Wed, Sep 05, 2012 at 08:33:35PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 30, 2012 at 05:38:35PM +0300, Michael S. Tsirkin wrote:
The following makes 'x86info -r' dump hypervisor leaf cpu ids
(for kvm this is
The following changes since commit b93196dc5af7729ff7cc50d3d322ab1a364aa14f:
net: fix some compiler warning in net/core/neighbour.c (2012-12-05 21:50:37
-0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next
for you to
Currently, kdump just makes all the logical processors leave VMX operation by
executing VMXOFF instruction, so any VMCSs active on the logical processors may
be corrupted. But, sometimes, we need the VMCSs to debug guest images contained
in the host vmcore. To prevent the corruption, we should
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
This patch provides a way to VMCLEAR VMCSs related to guests
on all cpus before executing the VMXOFF when doing kdump. This
is used to ensure the VMCSs in the vmcore updated and
non-corrupted.
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
The vmclear function will be assigned to the callback function pointer
when loading kvm-intel module. And the bitmap indicates whether we
should do VMCLEAR operation in kdump. The bits in the bitmap are
set/unset according to different conditions.
On 4 December 2012 13:37, Dong Aisheng b29...@freescale.com wrote:
On Tue, Dec 04, 2012 at 12:45:12PM +, Peter Maydell wrote:
On 4 December 2012 12:27, Dong Aisheng b29...@freescale.com wrote:
On Mon, Dec 03, 2012 at 01:22:07PM +, Peter Maydell wrote:
What we're really providing the
On Thu, Dec 06, 2012 at 11:36:48PM +0800, Zhang Yanfei wrote:
Currently, kdump just makes all the logical processors leave VMX operation by
executing VMXOFF instruction, so any VMCSs active on the logical processors
may
be corrupted. But, sometimes, we need the VMCSs to debug guest images
tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
head: 8f536b7697a0d40ef6b5fd04cf2c04953d5ca06f
commit: f23d1f4a116038c68df224deae6718fde87d8f0d [8/9] x86/kexec: VMCLEAR VMCSs
loaded on all cpus if necessary
sparse warnings:
+ arch/x86/kernel/crash.c:49:32: sparse: incompatible
On Thu, 2012-12-06 at 10:13 +0200, Michael S. Tsirkin wrote:
On Wed, Dec 05, 2012 at 08:39:26PM +, Ben Hutchings wrote:
On Mon, 2012-12-03 at 12:58 +0200, Michael S. Tsirkin wrote:
Add RFS support to virtio network device.
Add a new feature flag VIRTIO_NET_F_RFS for this feature, a
On Thu, Dec 06, 2012 at 08:36:52AM +0200, Gleb Natapov wrote:
On Thu, Dec 06, 2012 at 05:02:15AM +, Zhang, Yang Z wrote:
Zhang, Yang Z wrote on 2012-12-06:
Marcelo Tosatti wrote on 2012-12-06:
On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
Virtual interrupt delivery
On Thu, Dec 06, 2012 at 08:03:14PM +, Ben Hutchings wrote:
On Thu, 2012-12-06 at 10:13 +0200, Michael S. Tsirkin wrote:
On Wed, Dec 05, 2012 at 08:39:26PM +, Ben Hutchings wrote:
On Mon, 2012-12-03 at 12:58 +0200, Michael S. Tsirkin wrote:
Add RFS support to virtio network
On Thu, 2012-12-06 at 22:29 +0200, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2012 at 08:03:14PM +, Ben Hutchings wrote:
[...]
Since this doesn't seem to be intended to have *any* connection with the
existing core networking feature called RFS, perhaps you could find a
different name for
On Thu, Dec 06, 2012 at 08:53:59PM +, Ben Hutchings wrote:
On Thu, 2012-12-06 at 22:29 +0200, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2012 at 08:03:14PM +, Ben Hutchings wrote:
[...]
Since this doesn't seem to be intended to have *any* connection with the
existing core
Typo for the next pointer means we're walking random data here.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: sta...@vger.kernel.org [3.7]
---
Not sure if this will make 3.7, so preemptively adding the stable flag
virt/kvm/eventfd.c |2 +-
1 file changed, 1 insertion(+), 1
On Thu, 2012-12-06 at 23:01 +0200, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2012 at 08:53:59PM +, Ben Hutchings wrote:
On Thu, 2012-12-06 at 22:29 +0200, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2012 at 08:03:14PM +, Ben Hutchings wrote:
[...]
Since this doesn't seem to be
struct kvm_userspace_memory_region.flags is a u32 with a comment that
bits 0 ~ 15 are visible to userspace and the other bits are reserved
for kvm internal use. KVM_MEMSLOT_INVALID is the only internal use
flag and it has a comment that bits 16 ~ 31 are internally used and
the other bits are
We're currently offering a whopping 32 memory slots to user space, an
int is a bit excessive for storing this. We would like to increase
our memslots, but SHRT_MAX should be more than enough.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
include/linux/kvm_host.h |4 ++--
With the 3 private slots, this gives us a nice round 128 slots total.
The primary motivation for this is to support more assigned devices.
Each assigned device can theoretically use up to 8 slots (6 MMIO BARs,
1 ROM BAR, 1 spare for a split MSI-X table mapping) though it's far
more typical for a
There's no need for this to be an int, it holds a boolean.
Move to the end of the struct for alignment.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch/ia64/kvm/kvm-ia64.c |6 +++---
arch/powerpc/kvm/powerpc.c |4 ++--
arch/s390/kvm/kvm-s390.c |4 ++--
The iommu integration into memory slots expects memory slots to be
added or removed and doesn't handle the move case. We can unmap
slots from the iommu after we mark them invalid and map them before
installing the final memslot array. Also re-order the kmemdup vs
map so we don't leave iommu
If a slot is removed or moved in the guest physical address space, we
first allocate and install a new slot array with the invalidated
entry. The old array is then freed. We then proceed to allocate yet
another slot array to install the permanent replacement. Re-use the
original array when this
It's easy to confuse KVM_MEMORY_SLOTS and KVM_MEM_SLOTS_NUM. One is
the user accessible slots and the other is user + private. Make this
more obvious.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch/ia64/include/asm/kvm_host.h|2 +-
arch/ia64/kvm/kvm-ia64.c
Seems like everyone copied x86 and defined 4 private memory slots
that never actually get used. Even x86 only uses 3 of the 4. These
aren't exposed so there's no need to add padding.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch/ia64/include/asm/kvm_host.h|2 --
The API documentation states:
When changing an existing slot, it may be moved in the guest
physical memory space, or its flags may be modified.
An existing slot requires a non-zero npages (memory_size). The only
transition we should therefore allow for a non-existing slot should
This series does away with any kind of complicated resizing of the
slot array and simply does a one time increase. I do compact struct
kvm_memory_slot a bit to take better advantage of the space we are
using. This reduces each slot from 64 bytes (x86_64) to 56 bytes.
By enforcing the API around
The API documents that only flags and guest physical memory space can
be modified on an existing slot, but we don't enforce that the
userspace address cannot be modified. Instead we just ignore it.
This means that a user may think they've successfully moved both the
guest and user addresses, when
From: Nadav Amit nadav.a...@gmail.com
MOV immediate instruction (opcodes 0xB8-0xBF) may take 64-bit operand.
The previous emulation implementation assumes the operand is no longer than 32.
Adding OpImm64 for this matter.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=881579
Signed-off-by:
On Wed, Dec 05, 2012 at 08:51:37PM -0700, Alex Williamson wrote:
id_to_memslot seems like a good place to catch all the users since
that's the only way to get a slot from a slot id after the array is
sorted. We need to check both is the slot in bounds (EINVAL), but also
is it
On Thu, Dec 06, 2012 at 09:58:48PM -0200, Marcelo Tosatti wrote:
On Wed, Dec 05, 2012 at 08:51:37PM -0700, Alex Williamson wrote:
id_to_memslot seems like a good place to catch all the users since
that's the only way to get a slot from a slot id after the array is
sorted. We need to
On Thu, 2012-12-06 at 21:59 -0200, Marcelo Tosatti wrote:
On Thu, Dec 06, 2012 at 09:58:48PM -0200, Marcelo Tosatti wrote:
On Wed, Dec 05, 2012 at 08:51:37PM -0700, Alex Williamson wrote:
id_to_memslot seems like a good place to catch all the users since
that's the only way to get a
Marcelo Tosatti wrote on 2012-12-07:
On Thu, Dec 06, 2012 at 08:36:52AM +0200, Gleb Natapov wrote:
On Thu, Dec 06, 2012 at 05:02:15AM +, Zhang, Yang Z wrote:
Zhang, Yang Z wrote on 2012-12-06:
Marcelo Tosatti wrote on 2012-12-06:
On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
Ben Hutchings bhutchi...@solarflare.com writes:
If you want a name for the whole set of
features involved, I don't see any better name than 'multiqueue'/'MQ'.
OK, let's go back to multiqueue then, and perhaps refer to the current
receive steering as 'automatic'.
Cheers,
Rusty.
--
To
This removes the sparse warning:
arch/x86/kernel/crash.c:49:32: sparse: incompatible types in comparison
expression (different address spaces)
Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
---
arch/x86/include/asm/kexec.h |4
On 12/06/2012 09:00 PM, Michael S. Tsirkin wrote:
On Sun, Dec 02, 2012 at 09:33:53AM +0800, Asias He wrote:
diff --git a/drivers/vhost/Kconfig.blk b/drivers/vhost/Kconfig.blk
new file mode 100644
index 000..ff8ab76
--- /dev/null
+++ b/drivers/vhost/Kconfig.blk
@@ -0,0 +1,10 @@
+config
On Fri, Dec 07, 2012 at 01:00:18AM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2012-12-07:
How about to recaculate irr_pending according the VIRR on each vmexit?
No need really. Since HW can only clear VIRR the only situation that may
happen is that irr_pending will be true but
On Thu, Dec 06, 2012 at 09:55:10PM -0200, Marcelo Tosatti wrote:
From: Nadav Amit nadav.a...@gmail.com
MOV immediate instruction (opcodes 0xB8-0xBF) may take 64-bit operand.
The previous emulation implementation assumes the operand is no longer than
32.
Adding OpImm64 for this matter.
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also implements an API for mapping/unmapping pages for
guest PCI drivers and
- APIC read doesn't cause VM-Exit
- APIC write becomes trap-like
Signed-off-by: Kevin Tian kevin.t...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
arch/x86/include/asm/vmx.h |2 ++
arch/x86/kvm/lapic.c | 15 +++
arch/x86/kvm/lapic.h |2 ++
Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
manually, which is fully taken care of by the hardware. This needs
some special awareness into existing interrupr injection path:
- for pending interrupt, instead of direct injection, we may need
update architecture specific
APIC virtualization is a new feature which can eliminate most of VM exit
when vcpu handle a interrupt:
APIC register virtualization:
APIC read access doesn't cause APIC-access VM exits.
APIC write becomes trap-like.
Virtual interrupt delivery:
Virtual interrupt delivery
48 matches
Mail list logo
