On Wed, Apr 17, 2013 at 09:04:04PM +0200, Alexander Graf wrote:
Hi Marcelo / Gleb,
This is my current patch queue for ppc. Please pull for 3.10.
Pulled. Thanks.
Changes include:
- KVM: PPC: Fix in-kernel MMIO loads
- KVM: PPC: BookE: Fix 64-bit guest kernels with SMP
Alex
On Thu, Apr 18, 2013 at 02:34:25PM +0300, Abel Gordon wrote:
This series of patches implements shadow-vmcs capability for nested VMX.
Applied, thanks.
Shadow-vmcs - background and overview:
In Intel VMX, vmread and vmwrite privileged instructions are used by the
hypervisor to read and
On Thu, Apr 18, 2013 at 07:41:00AM +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
On Thu, Apr 18, 2013 at 09:38:14AM -0700, Andrew Honig wrote:
If userspace creates and destroys multiple VMs within the same process
we leak 20k of memory in the userspace process context per VM. This
patch frees the memory in kvm_arch_destroy_vm. If the process exits
without closing the
On Sun, Apr 14, 2013 at 09:04:26PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
The logic for checking if interrupts can be injected has to be applied
also on NMIs. The difference is that if NMI interception is on these
events are consumed and blocked by the VM exit.
On Mon, Apr 22, 2013 at 09:24:12AM +0530, Prasad Joshi wrote:
On Sun, Apr 21, 2013 at 2:49 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, Apr 21, 2013 at 02:12:21PM +0530, prasadjoshi.li...@gmail.com wrote:
From: Prasad Joshi prasadjoshi.li...@gmail.com
Write only SVM_KEY can be used to
Il 20/04/2013 10:52, Jan Kiszka ha scritto:
As we may emulate the loading of EFER on VM-entry and VM-exit, implement
the checks that VMX performs on the guest and host values on vmlaunch/
vmresume. Factor out kvm_valid_efer for this purpose which checks for
set reserved bits.
Signed-off-by:
On Thu, Apr 18, 2013 at 10:38:23AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 04:32:30PM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 10:09:53AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 09:05:53AM +0800, Asias He wrote:
Signed-off-by: Asias He
Il 21/04/2013 14:23, Borislav Petkov ha scritto:
On Sun, Apr 21, 2013 at 01:46:50PM +0200, Borislav Petkov wrote:
We probably need something with copying values to a temp variable or so.
Basically something like that:
case 2:
/*
* From MOVBE
On Sat, Apr 20, 2013 at 10:01:31PM +0300, Michael S. Tsirkin wrote:
On Fri, Apr 19, 2013 at 10:34:10AM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 11:21:54AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 04:59:08PM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 10:34:29AM
On Sun, Apr 21, 2013 at 10:09:29PM +0800, Xiao Guangrong wrote:
On 04/21/2013 09:03 PM, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
This patchset is based on my previous two patchset:
[PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu
On Mon, Apr 22, 2013 at 10:53:42AM +0200, Paolo Bonzini wrote:
Il 21/04/2013 14:23, Borislav Petkov ha scritto:
On Sun, Apr 21, 2013 at 01:46:50PM +0200, Borislav Petkov wrote:
We probably need something with copying values to a temp variable or so.
Basically something like that:
On Mon, Apr 22, 2013 at 11:38:10AM +0200, Borislav Petkov wrote:
On Mon, Apr 22, 2013 at 10:53:42AM +0200, Paolo Bonzini wrote:
Il 21/04/2013 14:23, Borislav Petkov ha scritto:
On Sun, Apr 21, 2013 at 01:46:50PM +0200, Borislav Petkov wrote:
We probably need something with copying values
On Mon, Apr 22, 2013 at 12:42:46PM +0300, Gleb Natapov wrote:
Btw, I wanted to ask: when kvm commits the results, does it look at
ctxt-op_bytes to know exactly how many bytes to write to the guest?
Because if it does, we can save ourselves the trouble here.
Or does it simply write both
On Sun, Apr 14, 2013 at 12:44:09PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
As we may emulate the loading of EFER on VM-entry and VM-exit, implement
the checks that VMX performs on the guest and host values on vmlaunch/
vmresume. Factor out kvm_valid_efer for this
On Mon, Apr 22, 2013 at 11:52:03AM +0200, Borislav Petkov wrote:
On Mon, Apr 22, 2013 at 12:42:46PM +0300, Gleb Natapov wrote:
Btw, I wanted to ask: when kvm commits the results, does it look at
ctxt-op_bytes to know exactly how many bytes to write to the guest?
Because if it does, we
Hi
I was wondering if anyone could help me with an issue with KVM and ISCSI.
If we restart a controller on our EqualLogic SAN or there are any
network interruptions on the storage network, KVM guests throw a
wobbler and their files systems go into read only(centos 5.9 guest
with virtio driver).
On Sun, 2013-04-21 at 17:12 -0400, Rik van Riel wrote:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
ISTR that paravirt ticket locks already do that and use the lsb to
indicate the unlock needs to perform
On Sun, Apr 21, 2013 at 12:35:08PM -0300, Marcelo Tosatti wrote:
On Sun, Apr 21, 2013 at 12:27:51PM -0300, Marcelo Tosatti wrote:
On Sun, Apr 21, 2013 at 04:03:46PM +0300, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
This patchset is based on my
On 04/22/2013 07:51 AM, Peter Zijlstra wrote:
On Sun, 2013-04-21 at 17:12 -0400, Rik van Riel wrote:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
ISTR that paravirt ticket locks already do that and use
On Mon, Apr 22, 2013 at 05:20:24PM +0800, Asias He wrote:
On Sat, Apr 20, 2013 at 10:01:31PM +0300, Michael S. Tsirkin wrote:
On Fri, Apr 19, 2013 at 10:34:10AM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 11:21:54AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 04:59:08PM
On Mon, Apr 22, 2013 at 04:53:27PM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 10:38:23AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 04:32:30PM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 10:09:53AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 09:05:53AM
On Mon, 22 Apr 2013 15:39:38 +0300
Gleb Natapov g...@redhat.com wrote:
Do not want kvm_set_memory (cases: DELETE/MOVE/CREATES) to be
suspectible to:
vcpu 1| kvm_set_memory
create shadow page
nuke shadow page
On Mon, Apr 22, 2013 at 12:58:12PM +0300, Gleb Natapov wrote:
For most instructions the decoder already sets op-bytes to correct
value, given that all flags a correctly specified in opcode table.
Explicit op-bytes setting should be done only if it cannot be
expressed by opcode flags.
MOVBE
https://bugzilla.kernel.org/show_bug.cgi?id=55201
Jay Ren yongjie@intel.com changed:
What|Removed |Added
Status|VERIFIED|CLOSED
--
Configure
https://bugzilla.kernel.org/show_bug.cgi?id=55421
Jay Ren yongjie@intel.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=55421
Jay Ren yongjie@intel.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure
https://bugzilla.kernel.org/show_bug.cgi?id=56971
Summary: [nested virt] L1 CPU Stuck when booting a L2 guest
Product: Virtualization
Version: unspecified
Kernel Version: 3.9.0-rc3
Platform: All
OS/Version: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=56981
Summary: [SR-IOV] Intel I350 NIC VF cannot work in a Windows
2008 guest.
Product: Virtualization
Version: unspecified
Kernel Version: 3.9.0-rc3
Platform: All
OS/Version:
https://bugzilla.kernel.org/show_bug.cgi?id=56971
Jay Ren yongjie@intel.com changed:
What|Removed |Added
Regression|No |Yes
--
Configure
https://bugzilla.kernel.org/show_bug.cgi?id=56981
--- Comment #1 from Jay Ren yongjie@intel.com 2013-04-22 14:43:00 ---
Created an attachment (id=99661)
-- (https://bugzilla.kernel.org/attachment.cgi?id=99661)
lspci info of the igbvf in kvm host
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=56981
--- Comment #2 from Jay Ren yongjie@intel.com 2013-04-22 14:43:25 ---
Created an attachment (id=99671)
-- (https://bugzilla.kernel.org/attachment.cgi?id=99671)
host dmesg
--
Configure bugmail:
On Mon, Apr 22, 2013 at 04:28:07PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 22, 2013 at 04:53:27PM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 10:38:23AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 04:32:30PM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 10:09:53AM
On Mon, Apr 22, 2013 at 04:17:04PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 22, 2013 at 05:20:24PM +0800, Asias He wrote:
On Sat, Apr 20, 2013 at 10:01:31PM +0300, Michael S. Tsirkin wrote:
On Fri, Apr 19, 2013 at 10:34:10AM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 11:21:54AM
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 22/04/2013 18:11, Juan Quintela ha scritto:
Hi
Please send in any agenda topics you are interested in.
* 1.5 pending patches
Paolo
Later, Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Mon, Apr 22, 2013 at 11:00:19PM +0800, Asias He wrote:
On Mon, Apr 22, 2013 at 04:28:07PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 22, 2013 at 04:53:27PM +0800, Asias He wrote:
On Thu, Apr 18, 2013 at 10:38:23AM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 18, 2013 at 04:32:30PM
On 04/22/2013 10:11 AM, Juan Quintela wrote:
Hi
Please send in any agenda topics you are interested in.
* What can libvirt expect in 1.5 for introspection of command-line support?
* What are the rules for adding optional parameters to existing QMP
commands? Would it help if we had
On Mon, Apr 22, 2013 at 1:58 AM, Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
The intuition is to
downgrade a fair lock to an unfair lock automatically upon preemption,
and preserve the fairness otherwise.
I also hope being little unfair, does not affect the original intention
Hi,
(I'm not subscribed to either list,)
using the word descriptor is misleading in the following sections:
2.4.1.2 Updating The Available Ring
[...] However, in general we can add many descriptors before we
update the idx fi eld (at which point they become visible to the
device), so
On 04/15/2013 01:58 AM, Jason Wang wrote:
Initializing them only when they're actually needed will do the trick here.
I don't see so much memory allocation with qemu, the main problem I
guess here is kvmtool does not support mergeable rx buffers ( does it?
). So guest must allocate 64K per
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
On 04/22/2013 07:51 AM, Peter Zijlstra wrote:
On Sun, 2013-04-21 at 17:12 -0400, Rik van Riel wrote:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
On 04/22/2013 03:49 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
If the native spin_lock code has been called already at
that time, the native code would still need to be modified
to increment the ticket number by 2, so we end up with a
compatible value in
On Mon, Apr 22, 2013 at 3:56 PM, Rik van Riel r...@redhat.com wrote:
On 04/22/2013 03:49 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
If the native spin_lock code has been called already at
that time, the native code would still need to be modified
to
On Mon, 2013-04-22 at 15:56 -0400, Rik van Riel wrote:
On 04/22/2013 03:49 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
If the native spin_lock code has been called already at
that time, the native code would still need to be modified
to increment the
On 04/22/2013 04:08 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 15:56 -0400, Rik van Riel wrote:
On 04/22/2013 03:49 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
If the native spin_lock code has been called already at
that time, the native code would
On Mon, 2013-04-22 at 16:32 -0400, Rik van Riel wrote:
IIRC one of the reasons was that the performance improvement wasn't
as obvious. Rescheduling VCPUs takes a fair amount of time, quite
probably more than the typical hold time of a spinlock.
IIRC it would spin for a while before
On Mon, Apr 22, 2013 at 4:08 PM, Peter Zijlstra pet...@infradead.org wrote:
I much prefer the entire series from Jeremy since it maintains the
ticket semantics and doesn't degrade the lock to unfair under
contention.
Now I suppose there's a reason its not been merged yet and I suspect
its
On Mon, 2013-04-22 at 22:44 +0200, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 16:32 -0400, Rik van Riel wrote:
IIRC one of the reasons was that the performance improvement wasn't
as obvious. Rescheduling VCPUs takes a fair amount of time, quite
probably more than the typical hold time
On 04/22/2013 04:46 PM, Jiannan Ouyang wrote:
It would still be very interesting to conduct more experiments to
compare these two, to see if the fairness enforced by pv_lock is
mandatory, and if preemptable-lock outperforms pv_lock in most cases,
and how do they work with PLE.
Given the
On Mon, Apr 22, 2013 at 4:44 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2013-04-22 at 16:32 -0400, Rik van Riel wrote:
IIRC one of the reasons was that the performance improvement wasn't
as obvious. Rescheduling VCPUs takes a fair amount of time, quite
probably more than the
On 04/22/2013 04:48 PM, Peter Zijlstra wrote:
Hmm.. it looked like under light overcommit the paravirt ticket lock
still had some gain (~10%) and of course it brings the fairness thing
which is always good.
I can only imagine the mess unfair + vcpu preemption can bring to guest
tasks.
If you
On 4/22/2013 1:50 PM, Jiannan Ouyang wrote:
On Mon, Apr 22, 2013 at 4:44 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2013-04-22 at 16:32 -0400, Rik van Riel wrote:
IIRC one of the reasons was that the performance improvement wasn't
as obvious. Rescheduling VCPUs takes a fair amount
On Mon, 2013-04-22 at 16:46 -0400, Jiannan Ouyang wrote:
On Mon, Apr 22, 2013 at 4:08 PM, Peter Zijlstra pet...@infradead.org wrote:
I much prefer the entire series from Jeremy since it maintains the
ticket semantics and doesn't degrade the lock to unfair under
contention.
Now I
On Mon, 2013-04-22 at 16:49 -0400, Rik van Riel wrote:
Given the fairly high cost of rescheduling a VCPU (which is likely
to include an IPI), versus the short hold time of most spinlocks,
I have the strong suspicion that your approach would win.
https://lkml.org/lkml/2012/5/2/101
If you
On Mon, Apr 22, 2013 at 4:55 PM, Peter Zijlstra pet...@infradead.org wrote:
Which pv_lock? The current pv spinlock mess is basically the old unfair
thing. The later patch series I referred to earlier implemented a
paravirt ticket lock, that should perform much better under overcommit.
Yes,
Rik van Riel r...@redhat.com writes:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
Spinning on a single bit is very inefficient, as you need to do
try lock in a loop which is very unfriendly to the MESI
On 04/22/2013 04:55 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 16:46 -0400, Jiannan Ouyang wrote:
- pv-preemptable-lock has much less performance variance compare to
pv_lock, because it adapts to preemption within VM,
other than using rescheduling that increase VM interference
I
On 04/22/2013 05:56 PM, Andi Kleen wrote:
Rik van Riel r...@redhat.com writes:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
Spinning on a single bit is very inefficient, as you need to do
try lock in a
On 04/18/2013 07:15:46 PM, Alexander Graf wrote:
On 18.04.2013, at 23:39, Scott Wood wrote:
Do we really want any default routes? There's no platform notion
of GSI
here, so how is userspace to know how the kernel set it up (or what
GSIs
are free to be used for new routes) -- other than
On 04/22/2013 05:21 PM, Gleb Natapov wrote:
On Sun, Apr 21, 2013 at 10:09:29PM +0800, Xiao Guangrong wrote:
On 04/21/2013 09:03 PM, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
This patchset is based on my previous two patchset:
[PATCH 0/2] KVM: x86:
Support mergable rx buffers for virtio-net. This helps reduce the amount
of memory the guest kernel has to allocate per rx vq.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
tools/kvm/include/kvm/uip.h | 4 ++--
tools/kvm/include/kvm/util.h | 3 +++
tools/kvm/net/uip/core.c | 54
Due to MQ support we may allocate a whole bunch of rx queues but
never use them. With this patch we'll safe the space used by
the receive buffers until they are actually in use:
sh-4.2# free -h
total used free sharedbuffers cached
Mem: 490M35M
Added e1000-devel list to see whether this's a known issue.
Best Regards,
Yongjie (Jay)
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
On Behalf Of bugzilla-dae...@bugzilla.kernel.org
Sent: Monday, April 22, 2013 10:41 PM
To:
On 04/23/2013 01:19 AM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
On 04/22/2013 07:51 AM, Peter Zijlstra wrote:
On Sun, 2013-04-21 at 17:12 -0400, Rik van Riel wrote:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the
On 04/22/2013 10:12 PM, Jiannan Ouyang wrote:
On Mon, Apr 22, 2013 at 1:58 AM, Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
[...]
static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock)
{
register struct __raw_tickets inc = { .tail = 1 };
+
On Mon, Apr 22, 2013 at 10:45:53PM +0900, Takuya Yoshikawa wrote:
On Mon, 22 Apr 2013 15:39:38 +0300
Gleb Natapov g...@redhat.com wrote:
Do not want kvm_set_memory (cases: DELETE/MOVE/CREATES) to be
suspectible to:
vcpu 1 | kvm_set_memory
create
Unless I'm mistaken, the size field was encoded 4 bits off and a wrong
value was used for 64-bit FP registers.
Signed-off-by: Christoffer Dall cd...@cs.columbia.edu
---
Documentation/virtual/kvm/api.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
HI Tomoki,
Thanks for you config file, but it is for linux-3.5-rc4, but the patches you
posted to the community was based on linux-3.6 as described in the following
link.
http://thread.gmane.org/gmane.linux.kernel/1353803
I also tested the config file on linux-3.6, still can not work.
Could
Sasha Levin sasha.le...@oracle.com writes:
Due to MQ support we may allocate a whole bunch of rx queues but
never use them. With this patch we'll safe the space used by
the receive buffers until they are actually in use:
Idea is good, implementation needs a tiny tweak:
@@ -912,8 +913,13 @@
Asias He as...@redhat.com writes:
On Mon, Apr 22, 2013 at 04:17:04PM +0300, Michael S. Tsirkin wrote:
+ evt = kzalloc(sizeof(*evt), GFP_KERNEL);
I think kzalloc not needed here, you init all fields.
Not really! evt-event.lun[4-7] is not initialized. It
Laszlo Ersek ler...@redhat.com writes:
Hi,
(I'm not subscribed to either list,)
using the word descriptor is misleading in the following sections:
Yes, I like the use of 'descriptor chains'. This is a definite
improvement.
Here's the diff I ended up with (massaged to minimize it).
Thanks!
On Tue, Apr 23, 2013 at 01:48:51PM +0930, Rusty Russell wrote:
Asias He as...@redhat.com writes:
On Mon, Apr 22, 2013 at 04:17:04PM +0300, Michael S. Tsirkin wrote:
+evt = kzalloc(sizeof(*evt), GFP_KERNEL);
I think kzalloc not needed here, you init all fields.
On 04/23/2013 12:13 AM, Rusty Russell wrote:
Sasha Levin sasha.le...@oracle.com writes:
Due to MQ support we may allocate a whole bunch of rx queues but
never use them. With this patch we'll safe the space used by
the receive buffers until they are actually in use:
Idea is good,
On 04/23/2013 02:31 AM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 16:49 -0400, Rik van Riel wrote:
Given the fairly high cost of rescheduling a VCPU (which is likely
to include an IPI), versus the short hold time of most spinlocks,
I have the strong suspicion that your approach would win.
On Mon, Apr 22, 2013 at 04:58:01PM +, Joji Mekkattuparamban (joji) wrote:
Greetings,
I have a SMP guest application, running on the 2.6.27 Linux kernel. The
application, originally written for bare metal, makes extensive use of the
TSC, by directly invoking rdtsc from the user space
On Mon, Apr 22, 2013 at 07:08:06PM -0400, Rik van Riel wrote:
On 04/22/2013 04:55 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 16:46 -0400, Jiannan Ouyang wrote:
- pv-preemptable-lock has much less performance variance compare to
pv_lock, because it adapts to preemption within VM,
On Wed, Apr 17, 2013 at 09:04:04PM +0200, Alexander Graf wrote:
Hi Marcelo / Gleb,
This is my current patch queue for ppc. Please pull for 3.10.
Pulled. Thanks.
Changes include:
- KVM: PPC: Fix in-kernel MMIO loads
- KVM: PPC: BookE: Fix 64-bit guest kernels with SMP
Alex
On 04/18/2013 07:15:46 PM, Alexander Graf wrote:
On 18.04.2013, at 23:39, Scott Wood wrote:
Do we really want any default routes? There's no platform notion
of GSI
here, so how is userspace to know how the kernel set it up (or what
GSIs
are free to be used for new routes) -- other than
79 matches
Mail list logo
