This reverts commit ea5d404655ba3b356d0c06d6a3c4f24112124522.
In commit 47283bef7ed356629467d1fac61687756e48f254(vhost: move memory
pointer to VQs), rcu_ operation has been replaced by mutex, and original
issue fixed in sea5d404655 has gone as well, we need to remove the
no-longer-used `locked'
On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote:
On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
include/linux/sched.h |8 +
kernel/sched/core.c| 15 +
Can you please not puke over the
On Fri, 10 Apr 2015 12:15:00 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
Hi,
This patchset allows vhost to be used with legacy virtio when guest and host
have a different endianness.
Patch 7 got rewritten according to Cornelia's and Michael's comments. I have
also introduced patch 8
On Thu, Apr 16, 2015 at 11:58:05AM -0700, Ben Serebrin wrote:
The host's decision to enable machine check exceptions should remain
in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset
and passed a slightly-modified 0 to the vmcs.guest_cr4 value.
Tested: Built.
On earlier
This reverts commit ea5d404655ba (vhost: fix release path lockdep checks)
In commit 47283bef7ed3 (vhost: move memory pointer to VQs), RCU
operations have been replaced by mutex, we need to remove the no longer
used `locked' parameter by reverting original patch.
Conflicts:
On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
include/linux/sched.h |8 +
kernel/sched/core.c| 15 +
Can you please not puke over the scheduler without Acks from at least
one maintainer?
I complained about this
On 17/04/2015 10:55, Greg KH wrote:
On Thu, Apr 16, 2015 at 11:58:05AM -0700, Ben Serebrin wrote:
The host's decision to enable machine check exceptions should remain
in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset
and passed a slightly-modified 0 to the
On 17/04/2015 12:36, Peter Zijlstra wrote:
Now you make everybody pay for your crap, x86-64 paravirt or not. Keep
the cost by those who need it.
Please take it out, ASAP.
I'll just implement the static key.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On Fri, Apr 17, 2015 at 12:38:07PM +0200, Paolo Bonzini wrote:
On 17/04/2015 12:36, Peter Zijlstra wrote:
Now you make everybody pay for your crap, x86-64 paravirt or not. Keep
the cost by those who need it.
Please take it out, ASAP.
I'll just implement the static key.
Can you
On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
On 17/04/2015 12:55, Peter Zijlstra wrote:
Also, it looks like you already do exactly this for other things, look
at:
kvm_sched_in()
kvm_arch_vcpu_load()
if (unlikely(vcpu-cpu != cpu) ... )
So no, I
On 17/04/2015 12:55, Peter Zijlstra wrote:
Also, it looks like you already do exactly this for other things, look
at:
kvm_sched_in()
kvm_arch_vcpu_load()
if (unlikely(vcpu-cpu != cpu) ... )
So no, I don't believe for one second you need this.
You're missing
On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
This patch introduces a specialized vfio platform driver for the
calxeda xgmac. On top of the generic vfio platform driver functionalities,
it implements the reset modality. This latter basically disables interrupts
and stops DMA transfers.
This patch introduces a specialized vfio platform driver for the
calxeda xgmac. On top of the generic vfio platform driver functionalities,
it implements the reset modality. This latter basically disables interrupts
and stops DMA transfers.
Code is inherited from calxeda xgmac native driver
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
The path this notifier is called from has nothing to do with those
costs.
How not? The task is going to incur those costs, it's not like half
a dozen extra instruction make any difference. But anyway...
Its attributed to the
In situations where the userspace driver is stopped abnormally and the
VFIO platform device is released, the assigned HW device currently is
left running. As a consequence the HW device might continue issuing IRQs
and performing DMA accesses.
On release, no physical IRQ handler is setup anymore.
This patch adds support for vfio platform reset. The modality only is
exposed when a specialized VFIO driver populates the reset callback.
For the generic vfio platform/amba driver, the modality is not supported
since the driver is by essence a metadriver and does not know how to
reset the
We intend to derive the platform driver into specialized ones, featuring
reset modality. In order to avoid duplication, let's export the functions
that can be reused in all vfio_platform drivers:
- get_platform_resource
- get_platform_irq
- vfio_platform_probe
- vfio_platform_remove
Practically,
On 17/04/2015 15:10, Peter Zijlstra wrote:
On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
On 17/04/2015 12:55, Peter Zijlstra wrote:
Also, it looks like you already do exactly this for other things, look
at:
kvm_sched_in()
kvm_arch_vcpu_load()
if
On 17/04/2015 11:17, Peter Zijlstra wrote:
On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote:
On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
include/linux/sched.h |8 +
kernel/sched/core.c| 15 +
On Fri, Apr 17, 2015 at 12:09:49PM +0200, Paolo Bonzini wrote:
On 17/04/2015 11:17, Peter Zijlstra wrote:
On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote:
On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
include/linux/sched.h |
On 17/04/2015 07:10, Wanpeng Li wrote:
Before the change, if guest CR4.MCE==0, then the machine check is
escalated to Catastrophic Error (CATERR) and the machine dies.
Could you point out which section of SDM describes that the machine check
is escalated to a CATERR if CR4.MCE==0?
It's
On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
This patch adds support for vfio platform reset. The modality only is
exposed when a specialized VFIO driver populates the reset callback.
For the generic vfio platform/amba driver, the modality is not supported
since the driver is by
On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
We intend to derive the platform driver into specialized ones, featuring
reset modality. In order to avoid duplication, let's export the functions
that can be reused in all vfio_platform drivers:
- get_platform_resource
- get_platform_irq
On 17/04/2015 15:43, Peter Zijlstra wrote:
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
The path this notifier is called from has nothing to do with those
costs.
Its attributed to the entity doing the migration, which can be the
wakeup path or a softirq. And we very much
Hi Alex,
On 04/17/2015 04:29 PM, Alex Williamson wrote:
On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
This patch introduces a specialized vfio platform driver for the
calxeda xgmac. On top of the generic vfio platform driver functionalities,
it implements the reset modality. This
On 2015-04-17 18:43, Radim Krčmář wrote:
2015-04-13 07:16+0200, Jan Kiszka:
PS: If someone has a good idea for a simple test case on machines
without IOMMU (like my current boxes), thus without a chance to use
device pass-through to stress guest PAT settings, I would be all ears.
Not a good
Thanks, Paolo, for the document reference and the fixup.
Greg: Sorry for the standard newbie gaffs.
On Fri, Apr 17, 2015 at 3:16 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 17/04/2015 07:10, Wanpeng Li wrote:
Before the change, if guest CR4.MCE==0, then the machine check is
escalated
2015-04-13 08:58+0200, Jan Kiszka:
When hardware supports the g_pat VMCB field, we can use it for emulating
the PAT configuration that the guest configures by writing to the
corresponding MSR.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Reviewed-by: Radim Krčmář rkrc...@redhat.com
2015-04-13 07:16+0200, Jan Kiszka:
Hi all,
while digging into the PAT topic for Jailhouse, I also wondered how KVM
deals with it. And I'm still not getting it complete - or there is a bug:
KVM intercepts all guest writes to the PAT MSR and instead keeps the
guest value in vcpu-arch.pat.
On Fri, Apr 17, 2015 at 09:57:12PM +0200, Paolo Bonzini wrote:
From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Fri, 17 Apr 2015 14:57:34 +0200
Subject: [PATCH] sched: add CONFIG_TASK_MIGRATION_NOTIFIER
The task
On Fri, Apr 17, 2015 at 12:01 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
On 17/04/2015 15:10, Peter Zijlstra wrote:
On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
On 17/04/2015 12:55, Peter Zijlstra wrote:
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
On 17/04/2015 15:10, Peter Zijlstra wrote:
On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
On 17/04/2015 12:55, Peter Zijlstra wrote:
Also, it looks like you already do exactly this for other things, look
at:
From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Fri, 17 Apr 2015 14:57:34 +0200
Subject: [PATCH] sched: add CONFIG_TASK_MIGRATION_NOTIFIER
The task migration notifier is only used in x86 paravirt. Make it
possible to
2015-04-17 19:12+0200, Jan Kiszka:
On 2015-04-17 18:43, Radim Krčmář wrote:
2015-04-13 07:16+0200, Jan Kiszka:
PS: If someone has a good idea for a simple test case on machines
without IOMMU (like my current boxes), thus without a chance to use
device pass-through to stress guest PAT
On Fri, Apr 17, 2015 at 4:39 PM, Andy Lutomirski l...@amacapital.net wrote:
On my box, vclock_gettime using kvm-clock is about 40 ns. An empty
syscall is about 33 ns. clock_gettime *should* be around 17 ns.
The clock_gettime syscall is about 73 ns.
Could we figure out why clock_gettime
On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski l...@amacapital.net wrote:
Muahaha. The auditors have invaded your system. (I did my little
benchmark with a more sensible configuration -- see way below).
Can you send the output of:
# auditctl -s
# auditctl -l
# auditctl -s
enabled
On Fri, Apr 17, 2015 at 1:18 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Fri, Apr 17, 2015 at 09:57:12PM +0200, Paolo Bonzini wrote:
From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Fri, 17 Apr 2015 14:57:34 +0200
On Fri, Apr 17, 2015 at 2:28 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Apr 17, 2015 at 4:39 PM, Andy Lutomirski l...@amacapital.net wrote:
On my box, vclock_gettime using kvm-clock is about 40 ns. An empty
syscall is about 33 ns. clock_gettime *should* be around 17 ns.
On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski l...@amacapital.net wrote:
Muahaha. The auditors have invaded your system. (I did my little
benchmark with a more sensible configuration -- see way below).
On Fri, Apr 17, 2015 at 03:25:28PM -0700, Andy Lutomirski wrote:
On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski l...@amacapital.net
wrote:
Muahaha. The auditors have invaded your system. (I did my
On Fri, Apr 17, 2015 at 05:04:29PM -0700, Andy Lutomirski wrote:
On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
From: Radim Krčmář rkrc...@redhat.com
As noted by Andy Lutomirski, kvm does not follow the documented version
protocol. Fix it.
Note: this bug
From: Radim Krčmář rkrc...@redhat.com
As noted by Andy Lutomirski, kvm does not follow the documented version
protocol. Fix it.
Note: this bug results in a race which can occur if the following three
conditions are met:
1) There is KVM guest time update (there is one every 5 minutes).
2)
On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
From: Radim Krčmář rkrc...@redhat.com
As noted by Andy Lutomirski, kvm does not follow the documented version
protocol. Fix it.
Note: this bug results in a race which can occur if the following three
conditions are
On Fri, Apr 17, 2015 at 05:04:29PM -0700, Andy Lutomirski wrote:
On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
From: Radim Krčmář rkrc...@redhat.com
As noted by Andy Lutomirski, kvm does not follow the documented version
protocol. Fix it.
Note: this bug
From: Radim Krčmář rkrc...@redhat.com
As noted by Andy Lutomirski, kvm does not follow the documented version
protocol. Fix it.
Note: this bug results in a race which can occur if the following three
conditions are met:
1) There is KVM guest time update (there is one every 5 minutes).
2)
45 matches
Mail list logo
