On 2012-03-22 00:17, Jan Kiszka wrote:
Some half a year ago when I posted my first attempt to refactor MSI
for KVM support, we came to the conclusion that it might suffice to do
transparent dynamic routing for user-space injected MSI messages. These
two patches now implement such an approach
So I was chasing a bug today when I realized that some drivers in qemu
do interesting things with memory regions.
More specifically, cirrus emulation constantly flips the linear
framebuffer between being mapped into the guest and being emulated MMIO
(the latter for the purpose of image blits).
On 27.03.2012 19:06, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 06:16:11 PM Peter Lieven wrote:
On 27.03.2012 18:12, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 05:58:01 PM Peter Lieven wrote:
On 27.03.2012 17:44, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 04:06:13 PM
On 03/28/2012 09:24 AM, Benjamin Herrenschmidt wrote:
So I was chasing a bug today when I realized that some drivers in qemu
do interesting things with memory regions.
They're usually called devices, drivers live in the guest.
More specifically, cirrus emulation constantly flips the linear
On 03/28/2012 12:47 AM, Marcelo Tosatti wrote:
vmx_set_cr0 is called from vcpu run context, therefore it expects
kvm-srcu to be held.
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On Wed, Mar 28, 2012 at 09:13:22AM +0200, Jan Kiszka wrote:
On 2012-03-22 00:17, Jan Kiszka wrote:
Some half a year ago when I posted my first attempt to refactor MSI
for KVM support, we came to the conclusion that it might suffice to do
transparent dynamic routing for user-space injected
On 2012-03-28 11:45, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 09:13:22AM +0200, Jan Kiszka wrote:
On 2012-03-22 00:17, Jan Kiszka wrote:
Some half a year ago when I posted my first attempt to refactor MSI
for KVM support, we came to the conclusion that it might suffice to do
On Wed, 2012-03-28 at 11:37 +0200, Avi Kivity wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse mapping from GPA ?).
We do have a reverse mapping, so we could
On 03/28/2012 11:59 AM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 11:37 +0200, Avi Kivity wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse mapping
On Wed, 2012-03-28 at 12:05 +0200, Avi Kivity wrote:
That's strange, the cirrus BAR allows the framebuffer and bitblt region
to coexist:
-7ffe (prio 0, RW): pci
000a-000b (prio 1, RW): cirrus-lowmem-container
On Wed, Mar 28, 2012 at 11:50:27AM +0200, Jan Kiszka wrote:
On 2012-03-28 11:45, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 09:13:22AM +0200, Jan Kiszka wrote:
On 2012-03-22 00:17, Jan Kiszka wrote:
Some half a year ago when I posted my first attempt to refactor MSI
for KVM
On 03/28/2012 12:17 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 12:05 +0200, Avi Kivity wrote:
That's strange, the cirrus BAR allows the framebuffer and bitblt region
to coexist:
-7ffe (prio 0, RW): pci
000a-000b (prio
On Wed, Mar 28, 2012 at 02:54:43PM +0800, Ren Mingxin wrote:
Hi,
The current virtblk's naming algorithm just supports 26^3
disks. If there are mass of virtblks(exceeding 26^3), there
will be disks with the same name.
According to sd_format_disk_name(), I add function
On 2012-03-28 12:47, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 11:50:27AM +0200, Jan Kiszka wrote:
On 2012-03-28 11:45, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 09:13:22AM +0200, Jan Kiszka wrote:
On 2012-03-22 00:17, Jan Kiszka wrote:
Some half a year ago when I posted my
On 03/22/2012 01:17 AM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This patch basically adds kvm_irqchip_send_msi, a service for sending
arbitrary MSI messages to KVM's in-kernel irqchip models.
As the current KVI API requires us to establish a static route from a
s/KVI/KVM/
On 03/21/2012 08:33 AM, Josh Triplett wrote:
Enable x86 feature-based autoloading for the kvm-intel module on CPUs
with X86_FEATURE_VMX.
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
On Wed, Mar 28, 2012 at 01:07:42PM +0200, Jan Kiszka wrote:
On 2012-03-28 12:47, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 11:50:27AM +0200, Jan Kiszka wrote:
On 2012-03-28 11:45, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 09:13:22AM +0200, Jan Kiszka wrote:
On 2012-03-22
On 2012-03-28 13:09, Avi Kivity wrote:
On 03/22/2012 01:17 AM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This patch basically adds kvm_irqchip_send_msi, a service for sending
arbitrary MSI messages to KVM's in-kernel irqchip models.
As the current KVI API requires us to
On 2012-03-28 13:31, Michael S. Tsirkin wrote:
Also, how would this support irqfd in the future? Will we have to
rip it all out and replace with per-device tracking that we
have today?
Irqfd and kvm device assignment will require additional interfaces (of
the kvm core in QEMU) via which you
On 03/28/2012 01:33 PM, Jan Kiszka wrote:
On 2012-03-28 13:09, Avi Kivity wrote:
On 03/22/2012 01:17 AM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This patch basically adds kvm_irqchip_send_msi, a service for sending
arbitrary MSI messages to KVM's in-kernel irqchip
On 2012-03-28 13:44, Avi Kivity wrote:
On 03/28/2012 01:33 PM, Jan Kiszka wrote:
On 2012-03-28 13:09, Avi Kivity wrote:
On 03/22/2012 01:17 AM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This patch basically adds kvm_irqchip_send_msi, a service for sending
arbitrary MSI
On Wed, Mar 28, 2012 at 01:09:25PM +0200, Avi Kivity wrote:
On 03/22/2012 01:17 AM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This patch basically adds kvm_irqchip_send_msi, a service for sending
arbitrary MSI messages to KVM's in-kernel irqchip models.
As the current
On 03/28/2012 01:54 PM, Jan Kiszka wrote:
interface transparent. We create those routes on demand and keep them
in a hash table. Succeeding messages can then search for an existing
route in the table first and reuse it whenever possible. If we should
run out of limited GSIs, we simply
On 03/27/2012 05:48 PM, Jaap Winius wrote:
Hi folks,
Recently I learned how to configure KVM with USB pass-though
functionality. In my case I configured my guest domain with this block
of code:
hostdev mode='subsystem' type='usb' managed='yes'
source
vendor id='0x0c93'/
On 03/28/2012 02:41 PM, Avi Kivity wrote:
On 03/27/2012 05:48 PM, Jaap Winius wrote:
Hi folks,
Recently I learned how to configure KVM with USB pass-though
functionality. In my case I configured my guest domain with this block
of code:
hostdev mode='subsystem' type='usb'
On 2012-03-28 14:32, Avi Kivity wrote:
On 03/28/2012 01:54 PM, Jan Kiszka wrote:
interface transparent. We create those routes on demand and keep them
in a hash table. Succeeding messages can then search for an existing
route in the table first and reuse it whenever possible. If we should
https://bugzilla.kernel.org/show_bug.cgi?id=42980
Avi Kivity a...@redhat.com changed:
What|Removed |Added
CC||a...@redhat.com
---
On 03/23/2012 02:23 AM, Rusty Russell wrote:
On Mon, 12 Mar 2012 02:52:41 -0400, Christoffer Dall
c.d...@virtualopensystems.com wrote:
@@ -236,6 +237,24 @@ int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
{
+ unsigned long cpsr;
https://bugzilla.kernel.org/show_bug.cgi?id=42980
--- Comment #2 from Luke-Jr luke-jr+linuxb...@utopios.org 2012-03-28
13:37:53 ---
IIRC, it was pretty out of the blue. I might have had one or both of two KVMs
running in the background at the time:
- 64-bit Gentoo with a Radeon 5850
https://bugzilla.kernel.org/show_bug.cgi?id=42980
--- Comment #3 from Avi Kivity a...@redhat.com 2012-03-28 13:45:25 ---
You're a brave one.
It wasn't the nested one (at least, it wasn't running in the guest's guest at
the moment of the crash), but it might be related.
--
Configure
https://bugzilla.kernel.org/show_bug.cgi?id=42980
--- Comment #4 from Luke-Jr luke-jr+linuxb...@utopios.org 2012-03-28
13:49:26 ---
I suppose I should mention I'd been running both of these stable for at least a
month now (and the GPU passthrough for nearly a full year). One factor that
On 03/27/12 17:48, Jaap Winius wrote:
Hi folks,
Recently I learned how to configure KVM with USB pass-though
functionality. In my case I configured my guest domain with this block
of code:
hostdev mode='subsystem' type='usb' managed='yes'
source
vendor id='0x0c93'/
https://bugzilla.kernel.org/show_bug.cgi?id=42980
--- Comment #5 from Avi Kivity a...@redhat.com 2012-03-28 15:07:25 ---
vcpu_enter_guest()
kvm_mmu_reload() // now root_hpa is valid
inject_pending_event()
vmx_interrupt_allowed()
nested_vmx_vmexit()
On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
On 2012-03-28 13:31, Michael S. Tsirkin wrote:
Also, how would this support irqfd in the future? Will we have to
rip it all out and replace with per-device tracking that we
have today?
Irqfd and kvm device assignment will
On Wed, Mar 28, 2012 at 01:44:41PM +0200, Avi Kivity wrote:
On 03/28/2012 01:33 PM, Jan Kiszka wrote:
On 2012-03-28 13:09, Avi Kivity wrote:
On 03/22/2012 01:17 AM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This patch basically adds kvm_irqchip_send_msi, a service
On 2012-03-28 17:43, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
On 2012-03-28 13:31, Michael S. Tsirkin wrote:
Also, how would this support irqfd in the future? Will we have to
rip it all out and replace with per-device tracking that we
have today?
On Wed, Mar 28, 2012 at 06:00:03PM +0200, Jan Kiszka wrote:
On 2012-03-28 17:43, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
On 2012-03-28 13:31, Michael S. Tsirkin wrote:
Also, how would this support irqfd in the future? Will we have to
rip it
On 03/23/2012 11:51 PM, Davidlohr Bueso wrote:
Avi, will you be taking this patch? I don't see it applied or for pull
in 3.4.
Applied now, thanks for the reminder.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm
I am happy to see this issue receiving some attention and second the
wish to see these patches be considered for further review and
inclusion in an upcoming release.
Overcommit is not as common in enterprise and single-tenant
virtualized environments as it is in multi-tenant environments, and
On Tue, Mar 27, 2012 at 3:24 PM, Roland Dreier rol...@purestorage.com wrote:
Just to follow up on this, it turns out this is a bug in how the
Mellanox firmware deals with FLR (function level reset). The
FW will be fixed in a future release, but in the meantime I've
been able to work around
On 2012-03-28 18:30, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 06:00:03PM +0200, Jan Kiszka wrote:
On 2012-03-28 17:43, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
On 2012-03-28 13:31, Michael S. Tsirkin wrote:
Also, how would this support
On 03/27/2012 04:55 PM, Michal Suchanek wrote:
Hello,
I downloaded a live CD of icaros here:
http://www.icarosdesktop.com/dl.htm
http://www.icarosdesktop.com/icarosfiles/IcarosLive_1_4_0.7z.exe
http://www.icarosdesktop.com/icarosfiles/IcarosLight_1_4_0.7z
I run kvm on
ii
On Wed, Mar 28, 2012 at 06:53:01PM +0200, Jan Kiszka wrote:
On 2012-03-28 18:30, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 06:00:03PM +0200, Jan Kiszka wrote:
On 2012-03-28 17:43, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
On 2012-03-28
On 2012-03-28 19:06, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 06:53:01PM +0200, Jan Kiszka wrote:
On 2012-03-28 18:30, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 06:00:03PM +0200, Jan Kiszka wrote:
On 2012-03-28 17:43, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at
Hello,
On 28 March 2012 19:02, Avi Kivity a...@redhat.com wrote:
0: 0f 2b 07 movntps %xmm0,(%edi)
3: 0f 2b 4f 10 movntps %xmm1,0x10(%edi)
7: 0f 2b 57 20 movntps %xmm2,0x20(%edi)
b: 0f 2b 5f 30 movntps %xmm3,0x30(%edi)
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user space as to manage
carefully.
By providing a
On 2012-03-28 19:47, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user
The current kvm_init_irq_routing() doesn't set up the used_gsi_bitmap
correctly, and as a consequence pins max_gsi to 32 when it really
should be 1024. I ran into this limitation while testing pci
passthrough, where I consistently got an -ENOSPC return from
kvm_get_irq_route_gsi() called from
On Wed, 2012-03-28 at 14:18 -0400, Jason Baron wrote:
The current kvm_init_irq_routing() doesn't set up the used_gsi_bitmap
correctly, and as a consequence pins max_gsi to 32 when it really
should be 1024. I ran into this limitation while testing pci
passthrough, where I consistently got an
On 03/28/2012 09:39 PM, Alan Meadows wrote:
I am happy to see this issue receiving some attention and second the
wish to see these patches be considered for further review and inclusion
in an upcoming release.
Overcommit is not as common in enterprise and single-tenant virtualized
environments
On 2012-03-28 20:20, Alex Williamson wrote:
On Wed, 2012-03-28 at 14:18 -0400, Jason Baron wrote:
The current kvm_init_irq_routing() doesn't set up the used_gsi_bitmap
correctly, and as a consequence pins max_gsi to 32 when it really
should be 1024. I ran into this limitation while testing pci
Enable x86 feature-based autoloading for the kvm-amd module on CPUs
with X86_FEATURE_SVM.
Signed-off-by: Josh Triplett j...@joshtriplett.org
---
On Wed, Mar 28, 2012 at 01:26:01PM +0200, Avi Kivity wrote:
On 03/21/2012 08:33 AM, Josh Triplett wrote:
Enable x86 feature-based autoloading for
On Wed, Mar 28, 2012 at 10:47 AM, Jan Kiszka jan.kis...@siemens.com wrote:
[...]
+4.61 KVM_SET_MSI
+
+Capability: KVM_CAP_SET_MSI
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msi (in)
+Returns: 0 on success, -1 on error
Is this the actual behavior? It looked to me like the
On 2012-03-28 21:58, Eric Northup wrote:
On Wed, Mar 28, 2012 at 10:47 AM, Jan Kiszka jan.kis...@siemens.com wrote:
[...]
+4.61 KVM_SET_MSI
+
+Capability: KVM_CAP_SET_MSI
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msi (in)
+Returns: 0 on success, -1 on error
Is this
If a virtio disk is open in guest and a disk resize operation is done,
(virsh blockresize), new size is not visible to tools like fdisk -l.
This seems to be happening as we update only part-nr_sects and not
bdev-bd_inode size.
Call revalidate_disk() which should take care of it. I tested growing
On Wed, 2012-03-28 at 12:51 +0200, Avi Kivity wrote:
Ah, then it's not a guest problem, it's how the chip was designed.
Newer chips do allow a workaround (GR31 bit 6):
6 System Source Location (Revision A): If this bit is ‘1’, the CL-GD546X
responds to write accesses at 000BC000h–000Bh
On Wed, 28 Mar 2012 15:05:55 +0200, Avi Kivity a...@redhat.com wrote:
On 03/23/2012 02:23 AM, Rusty Russell wrote:
On Mon, 12 Mar 2012 02:52:41 -0400, Christoffer Dall
c.d...@virtualopensystems.com wrote:
@@ -236,6 +237,24 @@ int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
On Wed, 28 Mar 2012 11:37:38 +0200
Avi Kivity a...@redhat.com wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse mapping from GPA ?).
We do have a reverse mapping,
Unfortunately, my time got stolen by other projects during the last two
weeks, but I wanted to post these before my wedding/honeymoon next week
(back May 7).
Nothing too radical, though the last one might effect anyone trying to
make an A9 guest. If so, they'll notice, and we can probably tag
On Wed, 28 Mar 2012 12:58:21 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Wed, Mar 28, 2012 at 02:54:43PM +0800, Ren Mingxin wrote:
Hi,
The current virtblk's naming algorithm just supports 26^3
disks. If there are mass of virtblks(exceeding 26^3), there
will be disks with the
Current guests don't do this, and it's not clear what we should do if they
try to turn on ECC or set various RAM latencies. When someone does this,
we'll have a better idea of what we should do about it.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c |5
As our emulation gets more sophisticated, we need to know what CPU model
we're dealing with. Particularly for some of the nastier workarounds.
Let's start with Cortex A-15. We can then test the MIDR elsewhere in the
code, knowing that it's one of a finite set of allowed values.
Signed-off-by:
Rather than just making all of c9 read-zero/write-discard, this changes
it to the explicit profiling registers we need. This is a start for the
future implementation were we actually implement performance monitoring,
and makes sure we're not discarding important things.
Signed-off-by: Rusty
On 03/28/2012 06:58 PM, Michael S. Tsirkin wrote:
On Wed, Mar 28, 2012 at 02:54:43PM +0800, Ren Mingxin wrote:
Hi,
The current virtblk's naming algorithm just supports 26^3
disks. If there are mass of virtblks(exceeding 26^3), there
will be disks with the same name.
According to
So I was chasing a bug today when I realized that some drivers in qemu
do interesting things with memory regions.
More specifically, cirrus emulation constantly flips the linear
framebuffer between being mapped into the guest and being emulated MMIO
(the latter for the purpose of image blits).
On 03/28/2012 09:24 AM, Benjamin Herrenschmidt wrote:
So I was chasing a bug today when I realized that some drivers in qemu
do interesting things with memory regions.
They're usually called devices, drivers live in the guest.
More specifically, cirrus emulation constantly flips the linear
On 03/28/2012 11:59 AM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 11:37 +0200, Avi Kivity wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse mapping
On Wed, 2012-03-28 at 12:05 +0200, Avi Kivity wrote:
That's strange, the cirrus BAR allows the framebuffer and bitblt region
to coexist:
-7ffe (prio 0, RW): pci
000a-000b (prio 1, RW): cirrus-lowmem-container
On 03/28/2012 12:17 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 12:05 +0200, Avi Kivity wrote:
That's strange, the cirrus BAR allows the framebuffer and bitblt region
to coexist:
-7ffe (prio 0, RW): pci
000a-000b (prio
On Wed, 28 Mar 2012 11:37:38 +0200
Avi Kivity a...@redhat.com wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse mapping from GPA ?).
We do have a reverse mapping,
70 matches
Mail list logo
