On Fri, Apr 19, 2013 at 04:06:26PM +0200, Alexander Graf wrote:
> Now that all the irq routing and irqfd pieces are generic, we can expose
> real irqchip support to all of KVM's internal helpers.
>
> This allows us to use irqfd with the in-kernel MPIC.
[snip]
> diff --git a/arch/powerpc/kvm/mpic.
Kernel should only try flushing pages which are managed by kernel.
pfn_to_page will returns junk struct page for pages not managed by kernel,
so if kernel will try to flush direct mapped memory or direct assigned device
mapping then it will work on junk struct page.
Signed-off-by: Bharat Bhushan
On Tue, Apr 23, 2013 at 08:19:02AM +0800, Xiao Guangrong wrote:
> 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:
>
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 V
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 spac
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 04/23/2013 12:13 AM, Rusty Russell wrote:
> Sasha Levin 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 ti
On Tue, Apr 23, 2013 at 01:48:51PM +0930, Rusty Russell wrote:
> Asias He 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 al
Laszlo Ersek 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!
Rusty.
--
Sasha Levin 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 @@ static int virtnet_s
Asias He 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
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
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
---
Documentation/virtual/kvm/api.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/api.tx
On Mon, Apr 22, 2013 at 10:45:53PM +0900, Takuya Yoshikawa wrote:
> On Mon, 22 Apr 2013 15:39:38 +0300
> Gleb Natapov wrote:
>
> > > > Do not want kvm_set_memory (cases: DELETE/MOVE/CREATES) to be
> > > > suspectible to:
> > > >
> > > > vcpu 1 | kvm_set_memory
> > > > crea
On 04/22/2013 10:12 PM, Jiannan Ouyang wrote:
On Mon, Apr 22, 2013 at 1:58 AM, Raghavendra K T
wrote:
[...]
static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock)
{
register struct __raw_tickets inc = { .tail = 1 };
+ unsigned int timeout = 0;
+ __t
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 lower
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: kvm@vger
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
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
---
tools/kvm/include/kvm/uip.h | 4 ++--
tools/kvm/include/kvm/util.h | 3 +++
tools/kvm/net/uip/core.c | 54 +
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]
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 th
On 04/22/2013 05:56 PM, Andi Kleen wrote:
Rik van Riel 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 ver
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 wou
Rik van Riel 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 state protocol.
On Mon, Apr 22, 2013 at 4:55 PM, Peter Zijlstra 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, it is a paravirt
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 s
On Mon, 2013-04-22 at 16:46 -0400, Jiannan Ouyang wrote:
> On Mon, Apr 22, 2013 at 4:08 PM, Peter Zijlstra 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 th
On 4/22/2013 1:50 PM, Jiannan Ouyang wrote:
On Mon, Apr 22, 2013 at 4:44 PM, 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
proba
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 Mon, Apr 22, 2013 at 4:44 PM, 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 tim
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 fairly
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 ho
On Mon, Apr 22, 2013 at 4:08 PM, Peter Zijlstra 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 !paravirt hotp
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 block
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 s
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 i
On Mon, Apr 22, 2013 at 3:56 PM, 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 in
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 e
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 th
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
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 field (at which point they become visible to the
device), s
On Mon, Apr 22, 2013 at 1:58 AM, Raghavendra K T
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
> of introducing ticket
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 intro
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:
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 majo
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
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:
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:
https://bugzilla.kernel.org/show_bug.cgi?id=56981
--- Comment #1 from Jay Ren 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/userprefs.
https://bugzilla.kernel.org/show_bug.cgi?id=56981
--- Comment #2 from Jay Ren 2013-04-22 14:43:25 ---
Created an attachment (id=99671)
--> (https://bugzilla.kernel.org/attachment.cgi?id=99671)
host dmesg
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
https://bugzilla.kernel.org/show_bug.cgi?id=56971
Jay Ren changed:
What|Removed |Added
Regression|No |Yes
--
Configure bugmail: https://bugzilla
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: Lin
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=55421
Jay Ren changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzi
https://bugzilla.kernel.org/show_bug.cgi?id=55201
Jay Ren changed:
What|Removed |Added
Status|VERIFIED|CLOSED
--
Configure bugmail: https://bugzi
https://bugzilla.kernel.org/show_bug.cgi?id=55421
Jay Ren changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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.
MOV
On Mon, 22 Apr 2013 15:39:38 +0300
Gleb Natapov 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 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:
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:
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 th
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 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 perfor
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 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 d
On Sun, Apr 14, 2013 at 12:44:09PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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
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 w
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 copyin
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 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 unnee
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:
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 MOV
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 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-of
On Mon, Apr 22, 2013 at 09:24:12AM +0530, Prasad Joshi wrote:
> On Sun, Apr 21, 2013 at 2:49 PM, Gleb Natapov wrote:
> > On Sun, Apr 21, 2013 at 02:12:21PM +0530, prasadjoshi.li...@gmail.com wrote:
> >> From: Prasad Joshi
> >>
> >> Write only SVM_KEY can be used to create a password protected mec
On Sun, Apr 14, 2013 at 09:04:26PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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.
>
> Signed-off-by: Ja
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 t
On Thu, Apr 18, 2013 at 07:41:00AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> 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
Applied, thanks.
> ---
> arch/x86/kvm/x86.c | 4 +++-
>
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
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
>
> A
80 matches
Mail list logo