On 09/14/2012 12:59 PM, Xiao Guangrong wrote:
Wrap the common operations into these two functions
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 53 +++
arch/x86/kvm/paging_tmpl.h | 16
On 09/19/2012 08:18 PM, Suresh Siddha wrote:
> These routines (kvm_load/put_guest_fpu()) are already called with
> preemption disabled but as you mentioned, we don't want the preemption
> to be disabled completely between the kvm_load_guest_fpu() and
> kvm_put_guest_fpu().
>
> Also KVM already
On 09/19/2012 04:54 PM, Alex Williamson wrote:
> On Wed, 2012-09-19 at 12:10 +0300, Avi Kivity wrote:
>> On 09/19/2012 12:08 PM, Michael S. Tsirkin wrote:
>>
>> >> Whoa. Can't we put the resampler entry somewhere we don't need to
>> >> search for it? Like
On 09/18/2012 06:03 AM, Andrew Theurer wrote:
> On Sun, 2012-09-16 at 11:55 +0300, Avi Kivity wrote:
>> On 09/14/2012 12:30 AM, Andrew Theurer wrote:
>>
>> > The concern I have is that even though we have gone through changes to
>> > help reduce the candidate
e.
>
> More importantly this will prevent the host process fpu from being
> corrupted.
>
> Signed-off-by: Suresh Siddha
> Cc: Avi Kivity
> ---
> arch/x86/kvm/x86.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c
On 09/19/2012 12:08 PM, Michael S. Tsirkin wrote:
>> Whoa. Can't we put the resampler entry somewhere we don't need to
>> search for it? Like a kvm_kernel_irq_routing_entry, that's indexed by
>> gsi already (kvm_irq_routing_table::rt_entries[gsi]).
>
> I'm not sure why would we bother
On 09/18/2012 06:16 AM, Alex Williamson wrote:
> To emulate level triggered interrupts, add a resample option to
> KVM_IRQFD. When specified, a new resamplefd is provided that notifies
> the user when the irqchip has been resampled by the VM. This may, for
> instance, indicate an EOI. Also in
On 09/18/2012 06:16 AM, Alex Williamson wrote:
To emulate level triggered interrupts, add a resample option to
KVM_IRQFD. When specified, a new resamplefd is provided that notifies
the user when the irqchip has been resampled by the VM. This may, for
instance, indicate an EOI. Also in this
On 09/19/2012 12:08 PM, Michael S. Tsirkin wrote:
Whoa. Can't we put the resampler entry somewhere we don't need to
search for it? Like a kvm_kernel_irq_routing_entry, that's indexed by
gsi already (kvm_irq_routing_table::rt_entries[gsi]).
I'm not sure why would we bother optimizing this,
this will prevent the host process fpu from being
corrupted.
Signed-off-by: Suresh Siddha suresh.b.sid...@intel.com
Cc: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
On 09/18/2012 06:03 AM, Andrew Theurer wrote:
On Sun, 2012-09-16 at 11:55 +0300, Avi Kivity wrote:
On 09/14/2012 12:30 AM, Andrew Theurer wrote:
The concern I have is that even though we have gone through changes to
help reduce the candidate vcpus we yield to, we still have a very poor
On 09/19/2012 04:54 PM, Alex Williamson wrote:
On Wed, 2012-09-19 at 12:10 +0300, Avi Kivity wrote:
On 09/19/2012 12:08 PM, Michael S. Tsirkin wrote:
Whoa. Can't we put the resampler entry somewhere we don't need to
search for it? Like a kvm_kernel_irq_routing_entry, that's indexed
On 09/19/2012 08:18 PM, Suresh Siddha wrote:
These routines (kvm_load/put_guest_fpu()) are already called with
preemption disabled but as you mentioned, we don't want the preemption
to be disabled completely between the kvm_load_guest_fpu() and
kvm_put_guest_fpu().
Also KVM already has the
On 09/14/2012 08:59 AM, Xiao Guangrong wrote:
> On 09/10/2012 05:26 PM, Xiao Guangrong wrote:
>> On 09/10/2012 05:09 PM, Avi Kivity wrote:
>>> On 09/07/2012 09:16 AM, Xiao Guangrong wrote:
>>>> mmu_notifier is the interface to broadcast the mm events to KVM, t
On 09/14/2012 12:30 AM, Andrew Theurer wrote:
> The concern I have is that even though we have gone through changes to
> help reduce the candidate vcpus we yield to, we still have a very poor
> idea of which vcpu really needs to run. The result is high cpu usage in
> the get_pid_task and still
On 09/14/2012 12:30 AM, Andrew Theurer wrote:
The concern I have is that even though we have gone through changes to
help reduce the candidate vcpus we yield to, we still have a very poor
idea of which vcpu really needs to run. The result is high cpu usage in
the get_pid_task and still some
On 09/14/2012 08:59 AM, Xiao Guangrong wrote:
On 09/10/2012 05:26 PM, Xiao Guangrong wrote:
On 09/10/2012 05:09 PM, Avi Kivity wrote:
On 09/07/2012 09:16 AM, Xiao Guangrong wrote:
mmu_notifier is the interface to broadcast the mm events to KVM, the
tracepoints introduced in this patch can
On 09/11/2012 09:27 PM, Andrew Theurer wrote:
>
> So, having both is probably not a good idea. However, I feel like
> there's more work to be done. With no over-commit (10 VMs), total
> throughput is 23427 +/- 2.76%. A 2x over-commit will no doubt have some
> overhead, but a reduction to ~4500
On 09/12/2012 09:11 PM, Jiri Slaby wrote:
> On 09/12/2012 10:18 AM, Avi Kivity wrote:
>> On 09/12/2012 11:13 AM, Jiri Slaby wrote:
>>>
>>>> Please provide the output of vmxcap
>>>> (http://goo.gl/c5lUO),
>>>
>>> Unrestricted g
On 09/12/2012 09:11 PM, Jiri Slaby wrote:
On 09/12/2012 10:18 AM, Avi Kivity wrote:
On 09/12/2012 11:13 AM, Jiri Slaby wrote:
Please provide the output of vmxcap
(http://goo.gl/c5lUO),
Unrestricted guest no
The big real mode fixes.
and a snapshot
On 09/11/2012 09:27 PM, Andrew Theurer wrote:
So, having both is probably not a good idea. However, I feel like
there's more work to be done. With no over-commit (10 VMs), total
throughput is 23427 +/- 2.76%. A 2x over-commit will no doubt have some
overhead, but a reduction to ~4500 is
On 09/12/2012 06:44 PM, Marcelo Tosatti wrote:
> On Wed, Sep 12, 2012 at 06:34:33PM +0300, Avi Kivity wrote:
>> On 09/11/2012 05:39 PM, Marcelo Tosatti wrote:
>> > On Tue, Sep 11, 2012 at 12:18:22PM +0300, Avi Kivity wrote:
>> >> > The same can happe
On 09/11/2012 05:39 PM, Marcelo Tosatti wrote:
> On Tue, Sep 11, 2012 at 12:18:22PM +0300, Avi Kivity wrote:
>> > The same can happen with slot deletion, for example.
>> >
>> > Userspace (which performed the modification which can result in faults
>> >
On 09/12/2012 11:13 AM, Jiri Slaby wrote:
>
>> Please provide the output of vmxcap
>> (http://goo.gl/c5lUO),
>
> Unrestricted guest no
The big real mode fixes.
>
>> and a snapshot of kvm_stat while the guest is hung.
>
> kvm statistics
>
> exits
On 09/12/2012 07:40 AM, Fengguang Wu wrote:
> Hi,
>
> 3 of my test boxes running v3.5 kernel become unaccessible and I find
> two of them kept emitting this dmesg:
>
> vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit
> reason is 0x31
>
> The other one has froze and the
On 09/11/2012 10:41 PM, Jiri Slaby wrote:
> On 09/11/2012 09:03 PM, Marcelo Tosatti wrote:
>> On Tue, Sep 11, 2012 at 08:11:36PM +0200, Jiri Slaby wrote:
>>> Hi,
>>>
>>> it looks like an update from next-20120824 to next-20120910 makes kvm
>>> defunct. When I try to run qemu, it loops forever
On 09/11/2012 10:41 PM, Jiri Slaby wrote:
On 09/11/2012 09:03 PM, Marcelo Tosatti wrote:
On Tue, Sep 11, 2012 at 08:11:36PM +0200, Jiri Slaby wrote:
Hi,
it looks like an update from next-20120824 to next-20120910 makes kvm
defunct. When I try to run qemu, it loops forever without printing
On 09/12/2012 07:40 AM, Fengguang Wu wrote:
Hi,
3 of my test boxes running v3.5 kernel become unaccessible and I find
two of them kept emitting this dmesg:
vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit
reason is 0x31
The other one has froze and the above
On 09/12/2012 11:13 AM, Jiri Slaby wrote:
Please provide the output of vmxcap
(http://goo.gl/c5lUO),
Unrestricted guest no
The big real mode fixes.
and a snapshot of kvm_stat while the guest is hung.
kvm statistics
exits
On 09/11/2012 05:39 PM, Marcelo Tosatti wrote:
On Tue, Sep 11, 2012 at 12:18:22PM +0300, Avi Kivity wrote:
The same can happen with slot deletion, for example.
Userspace (which performed the modification which can result in faults
to non-existant/read-only/.../new-tag memslot), must
On 09/12/2012 06:44 PM, Marcelo Tosatti wrote:
On Wed, Sep 12, 2012 at 06:34:33PM +0300, Avi Kivity wrote:
On 09/11/2012 05:39 PM, Marcelo Tosatti wrote:
On Tue, Sep 11, 2012 at 12:18:22PM +0300, Avi Kivity wrote:
The same can happen with slot deletion, for example.
Userspace (which
On 09/11/2012 01:31 AM, Marcelo Tosatti wrote:
> On Fri, Sep 07, 2012 at 05:56:39PM +0800, Xiao Guangrong wrote:
>> On 09/06/2012 10:09 PM, Avi Kivity wrote:
>> > On 08/22/2012 03:47 PM, Xiao Guangrong wrote:
>> >> On 08/22/2012 08:06 PM, Avi Kivity wrote:
>&
On 09/11/2012 01:31 AM, Marcelo Tosatti wrote:
On Fri, Sep 07, 2012 at 05:56:39PM +0800, Xiao Guangrong wrote:
On 09/06/2012 10:09 PM, Avi Kivity wrote:
On 08/22/2012 03:47 PM, Xiao Guangrong wrote:
On 08/22/2012 08:06 PM, Avi Kivity wrote:
On 08/21/2012 06:03 AM, Xiao Guangrong wrote
Linus, please pull from the repo and branch at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.6-2
to receive a trio of KVM fixes: incorrect lookup of guest cpuid,
an uninitialized variable fix, and error path cleanup fix.
Shortlog/diffstat follow.
On 09/07/2012 09:16 AM, Xiao Guangrong wrote:
> mmu_notifier is the interface to broadcast the mm events to KVM, the
> tracepoints introduced in this patch can trace all these events, it is
> very helpful for us to notice and fix the bug caused by mm
There is nothing kvm specific here. Perhaps
On 09/10/2012 11:37 AM, Xiao Guangrong wrote:
> On 09/10/2012 04:22 PM, Avi Kivity wrote:
>> On 09/07/2012 09:13 AM, Xiao Guangrong wrote:
>>> We can not directly call kvm_release_pfn_clean to release the pfn
>>> since we can meet noslot pfn which is used to ca
On 09/07/2012 09:14 AM, Xiao Guangrong wrote:
> This bug was triggered:
> [ 4220.198458] BUG: unable to handle kernel paging request at fffe
> [ 4220.203907] IP: [] put_page+0xf/0x34
> ..
> [ 4220.237326] Call Trace:
> [ 4220.237361] [] kvm_arch_destroy_vm+0xf9/0x101 [kvm]
> [
On 09/07/2012 09:15 AM, Xiao Guangrong wrote:
> Checking the return of kvm_mmu_get_page is unnecessary since it is
> guaranteed by memory cache
>
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe
On 09/07/2012 09:13 AM, Xiao Guangrong wrote:
> We can not directly call kvm_release_pfn_clean to release the pfn
> since we can meet noslot pfn which is used to cache mmio info into
> spte
>
> Introduce mmu_release_pfn_clean to do this kind of thing
>
> Signed-off-by: Xiao Guangrong
> ---
>
On 09/09/2012 06:10 PM, Liu, Jinsong wrote:
> Avi Kivity wrote:
>> On 09/09/2012 05:54 PM, Liu, Jinsong wrote:
>>>>
>>>> hrtimers is an intrusive feature, I don't think we should
>>>> force-enable it. Please change it to a depends on.
>>>
&g
On 09/09/2012 06:10 PM, Liu, Jinsong wrote:
Avi Kivity wrote:
On 09/09/2012 05:54 PM, Liu, Jinsong wrote:
hrtimers is an intrusive feature, I don't think we should
force-enable it. Please change it to a depends on.
Hmm, if it changed as
config KVM
depends on HIGH_RES_TIMERS
On 09/07/2012 09:13 AM, Xiao Guangrong wrote:
We can not directly call kvm_release_pfn_clean to release the pfn
since we can meet noslot pfn which is used to cache mmio info into
spte
Introduce mmu_release_pfn_clean to do this kind of thing
Signed-off-by: Xiao Guangrong
On 09/07/2012 09:15 AM, Xiao Guangrong wrote:
Checking the return of kvm_mmu_get_page is unnecessary since it is
guaranteed by memory cache
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe
On 09/07/2012 09:14 AM, Xiao Guangrong wrote:
This bug was triggered:
[ 4220.198458] BUG: unable to handle kernel paging request at fffe
[ 4220.203907] IP: [81104d85] put_page+0xf/0x34
..
[ 4220.237326] Call Trace:
[ 4220.237361] [a03830d0]
On 09/10/2012 11:37 AM, Xiao Guangrong wrote:
On 09/10/2012 04:22 PM, Avi Kivity wrote:
On 09/07/2012 09:13 AM, Xiao Guangrong wrote:
We can not directly call kvm_release_pfn_clean to release the pfn
since we can meet noslot pfn which is used to cache mmio info into
spte
Introduce
On 09/07/2012 09:16 AM, Xiao Guangrong wrote:
mmu_notifier is the interface to broadcast the mm events to KVM, the
tracepoints introduced in this patch can trace all these events, it is
very helpful for us to notice and fix the bug caused by mm
There is nothing kvm specific here. Perhaps this
Linus, please pull from the repo and branch at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.6-2
to receive a trio of KVM fixes: incorrect lookup of guest cpuid,
an uninitialized variable fix, and error path cleanup fix.
Shortlog/diffstat follow.
On 09/09/2012 05:54 PM, Liu, Jinsong wrote:
>>
>> hrtimers is an intrusive feature, I don't think we should force-enable
>> it. Please change it to a depends on.
>
> Hmm, if it changed as
> config KVM
> depends on HIGH_RES_TIMERS
> The item 'Kernel-based Virtual Machine (KVM) support
On 09/07/2012 03:07 PM, Liu, Jinsong wrote:
> Avi Kivity wrote:
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 148ed66..0e64997 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -2210,7 +2210,
On 09/07/2012 12:56 PM, Xiao Guangrong wrote:
> On 09/06/2012 10:09 PM, Avi Kivity wrote:
>> On 08/22/2012 03:47 PM, Xiao Guangrong wrote:
>>> On 08/22/2012 08:06 PM, Avi Kivity wrote:
>>>> On 08/21/2012 06:03 AM, Xiao Guangrong wrote:
>>>>> I
On 09/07/2012 02:14 PM, Jan Kiszka wrote:
>>
>> $ grep __KVM_HAVE include/linux/kvm.h | wc -l
>> 20
>
> Yes, mistakes of the past.
>
>>
>> As your suggestion, userspace will always use the CAP even if the CAP
>> is not really supported. We do not need care the overload on other arches?
>
>
On 09/07/2012 02:14 PM, Jan Kiszka wrote:
$ grep __KVM_HAVE include/linux/kvm.h | wc -l
20
Yes, mistakes of the past.
As your suggestion, userspace will always use the CAP even if the CAP
is not really supported. We do not need care the overload on other arches?
Generally,
On 09/07/2012 12:56 PM, Xiao Guangrong wrote:
On 09/06/2012 10:09 PM, Avi Kivity wrote:
On 08/22/2012 03:47 PM, Xiao Guangrong wrote:
On 08/22/2012 08:06 PM, Avi Kivity wrote:
On 08/21/2012 06:03 AM, Xiao Guangrong wrote:
Introduce write_readonly_mem in mmio-exit-info to indicate this exit
On 09/07/2012 03:07 PM, Liu, Jinsong wrote:
Avi Kivity wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 148ed66..0e64997 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2210,7 +2210,11 @@ int kvm_dev_ioctl_check_extension(long ext)
r
On 09/09/2012 05:54 PM, Liu, Jinsong wrote:
hrtimers is an intrusive feature, I don't think we should force-enable
it. Please change it to a depends on.
Hmm, if it changed as
config KVM
depends on HIGH_RES_TIMERS
The item 'Kernel-based Virtual Machine (KVM) support (NEW)' even
On 08/22/2012 03:47 PM, Xiao Guangrong wrote:
> On 08/22/2012 08:06 PM, Avi Kivity wrote:
>> On 08/21/2012 06:03 AM, Xiao Guangrong wrote:
>>> Introduce write_readonly_mem in mmio-exit-info to indicate this exit is
>>> caused by write access on readonly mem
On 09/04/2012 06:07 PM, Liu, Jinsong wrote:
> From 728a17e2de591b557c3c8ba31076b4bf2ca5ab42 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong
> Date: Wed, 5 Sep 2012 03:18:15 +0800
> Subject: [PATCH] KVM: tsc deadline timer works only when hrtimer high
> resolution configured
>
> This is for 2
On 09/06/2012 02:27 PM, Tomoki Sekiyama wrote:
> This RFC patch series provides facility to dedicate CPUs to KVM guests
> and enable the guests to handle interrupts from passed-through PCI devices
> directly (without VM exit and relay by the host).
>
> With this feature, we can improve throughput
On 09/06/2012 02:31 PM, Avi Kivity wrote:
> On 09/06/2012 02:27 PM, Tomoki Sekiyama wrote:
>> Split memory hotplug function from cpu_up() as cpu_memory_up(), which will
>> be used for assigning memory area to off-lined cpus at following patch
>> in this series.
>&g
On 09/06/2012 02:27 PM, Tomoki Sekiyama wrote:
> Split memory hotplug function from cpu_up() as cpu_memory_up(), which will
> be used for assigning memory area to off-lined cpus at following patch
> in this series.
>
Can post a summary containing both the general outline for people
reading this
On 09/06/2012 12:54 AM, Davidlohr Bueso wrote:
> On Mon, 2012-09-03 at 12:11 +0300, Avi Kivity wrote:
>> On 09/03/2012 02:27 AM, Davidlohr Bueso wrote:
>> > On Fri, 2012-08-31 at 14:37 -0300, Marcelo Tosatti wrote:
>> >> On Fri, Aug 31, 2012 at 06:10:48P
On 09/06/2012 12:54 AM, Davidlohr Bueso wrote:
On Mon, 2012-09-03 at 12:11 +0300, Avi Kivity wrote:
On 09/03/2012 02:27 AM, Davidlohr Bueso wrote:
On Fri, 2012-08-31 at 14:37 -0300, Marcelo Tosatti wrote:
On Fri, Aug 31, 2012 at 06:10:48PM +0200, Davidlohr Bueso wrote:
For processors
On 09/06/2012 02:27 PM, Tomoki Sekiyama wrote:
Split memory hotplug function from cpu_up() as cpu_memory_up(), which will
be used for assigning memory area to off-lined cpus at following patch
in this series.
Can post a summary containing both the general outline for people
reading this for
On 09/06/2012 02:31 PM, Avi Kivity wrote:
On 09/06/2012 02:27 PM, Tomoki Sekiyama wrote:
Split memory hotplug function from cpu_up() as cpu_memory_up(), which will
be used for assigning memory area to off-lined cpus at following patch
in this series.
Can post a summary containing both
On 09/06/2012 02:27 PM, Tomoki Sekiyama wrote:
This RFC patch series provides facility to dedicate CPUs to KVM guests
and enable the guests to handle interrupts from passed-through PCI devices
directly (without VM exit and relay by the host).
With this feature, we can improve throughput and
On 09/04/2012 06:07 PM, Liu, Jinsong wrote:
From 728a17e2de591b557c3c8ba31076b4bf2ca5ab42 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong jinsong@intel.com
Date: Wed, 5 Sep 2012 03:18:15 +0800
Subject: [PATCH] KVM: tsc deadline timer works only when hrtimer high
resolution configured
This
On 08/22/2012 03:47 PM, Xiao Guangrong wrote:
On 08/22/2012 08:06 PM, Avi Kivity wrote:
On 08/21/2012 06:03 AM, Xiao Guangrong wrote:
Introduce write_readonly_mem in mmio-exit-info to indicate this exit is
caused by write access on readonly memslot
Please document this in chapter 5
On 09/05/2012 06:28 PM, Michael S. Tsirkin wrote:
>> gsi 3 is configured as edge in the ioapic. It has (unusually) two
>> inputs: one driven by userspace, the other by irqfd.
>>
>> cpu 0cpu 1
>> -
>> irqfd: set to 1
>> ioapic:
On 09/05/2012 06:13 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 05, 2012 at 05:59:46PM +0300, Avi Kivity wrote:
>> On 09/05/2012 05:51 PM, Michael S. Tsirkin wrote:
>> > On Wed, Sep 05, 2012 at 05:35:43PM +0300, Avi Kivity wrote:
>> >> On 08/22/2012 03:4
On 09/05/2012 06:07 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 05, 2012 at 05:46:17PM +0300, Avi Kivity wrote:
>> On 08/21/2012 10:29 PM, Alex Williamson wrote:
>> > KVM_IRQFD currently uses the reserved KVM_USERSPACE_IRQ_SOURCE_ID
>> > which is also shared with users
On 09/05/2012 06:09 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 05, 2012 at 05:51:53PM +0300, Michael S. Tsirkin wrote:
>> On Wed, Sep 05, 2012 at 05:35:43PM +0300, Avi Kivity wrote:
>> > On 08/22/2012 03:41 AM, Michael S. Tsirkin wrote:
>> > >>
>> > &g
On 09/05/2012 05:51 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 05, 2012 at 05:35:43PM +0300, Avi Kivity wrote:
>> On 08/22/2012 03:41 AM, Michael S. Tsirkin wrote:
>> >>
>> >> I assumed you were pointing out the level vs edge interaction. If we
>> >&g
On 08/21/2012 10:29 PM, Alex Williamson wrote:
> For VFIO based device assignment we'd like a mechanism to allow level
> triggered interrutps to be directly injected into KVM. KVM_IRQFD
> already allows this for edge triggered interrupts, but for level, we
> need to watch for acknowledgement of
On 08/21/2012 10:29 PM, Alex Williamson wrote:
> KVM_IRQFD currently uses the reserved KVM_USERSPACE_IRQ_SOURCE_ID
> which is also shared with userspace injection methods like
> KVM_IRQ_LINE. This can cause a conflict if an irqfd triggers on
> a GSI asserted through KVM_IRQ_LINE. Move irqfd to
On 08/21/2012 10:28 PM, Alex Williamson wrote:
> Here's the much anticipated re-write of support for level irqfds. As
> Michael suggested, I've rolled the eoi/ack notification fd into
> KVM_IRQFD as a new mode. For lack of a better name, as there seems to
> be objections to associating this
On 08/22/2012 03:41 AM, Michael S. Tsirkin wrote:
>>
>> I assumed you were pointing out the level vs edge interaction. If we
>> call that a userspace bug, I can just drop this. Thanks,
>>
>> Alex
>
> level is userspace bug I think :)
I don't see how it's a bug. Suppose we have a vfio device
On 09/04/2012 09:41 PM, Michael S. Tsirkin wrote:
> On Tue, Sep 04, 2012 at 07:34:19PM +0300, Avi Kivity wrote:
>> On 08/31/2012 12:56 PM, Michael S. Tsirkin wrote:
>> > On Fri, Aug 31, 2012 at 11:36:07AM +0200, Sasha Levin wrote:
>> >> On 08/30/2012 03:3
On 09/04/2012 03:51 PM, Mathias Krause wrote:
> On Tue, Sep 4, 2012 at 2:13 PM, Avi Kivity wrote:
>> On 09/04/2012 03:09 PM, Avi Kivity wrote:
>>> On 08/30/2012 02:30 AM, Mathias Krause wrote:
>>>> As the the compiler ensures that the memory operand is always al
On 09/04/2012 03:51 PM, Mathias Krause wrote:
On Tue, Sep 4, 2012 at 2:13 PM, Avi Kivity a...@redhat.com wrote:
On 09/04/2012 03:09 PM, Avi Kivity wrote:
On 08/30/2012 02:30 AM, Mathias Krause wrote:
As the the compiler ensures that the memory operand is always aligned
to a 16 byte memory
On 09/04/2012 09:41 PM, Michael S. Tsirkin wrote:
On Tue, Sep 04, 2012 at 07:34:19PM +0300, Avi Kivity wrote:
On 08/31/2012 12:56 PM, Michael S. Tsirkin wrote:
On Fri, Aug 31, 2012 at 11:36:07AM +0200, Sasha Levin wrote:
On 08/30/2012 03:38 PM, Michael S. Tsirkin wrote:
+static unsigned
On 08/22/2012 03:41 AM, Michael S. Tsirkin wrote:
I assumed you were pointing out the level vs edge interaction. If we
call that a userspace bug, I can just drop this. Thanks,
Alex
level is userspace bug I think :)
I don't see how it's a bug. Suppose we have a vfio device that shares
On 08/21/2012 10:28 PM, Alex Williamson wrote:
Here's the much anticipated re-write of support for level irqfds. As
Michael suggested, I've rolled the eoi/ack notification fd into
KVM_IRQFD as a new mode. For lack of a better name, as there seems to
be objections to associating this
On 08/21/2012 10:29 PM, Alex Williamson wrote:
KVM_IRQFD currently uses the reserved KVM_USERSPACE_IRQ_SOURCE_ID
which is also shared with userspace injection methods like
KVM_IRQ_LINE. This can cause a conflict if an irqfd triggers on
a GSI asserted through KVM_IRQ_LINE. Move irqfd to it's
On 08/21/2012 10:29 PM, Alex Williamson wrote:
For VFIO based device assignment we'd like a mechanism to allow level
triggered interrutps to be directly injected into KVM. KVM_IRQFD
already allows this for edge triggered interrupts, but for level, we
need to watch for acknowledgement of the
On 09/05/2012 05:51 PM, Michael S. Tsirkin wrote:
On Wed, Sep 05, 2012 at 05:35:43PM +0300, Avi Kivity wrote:
On 08/22/2012 03:41 AM, Michael S. Tsirkin wrote:
I assumed you were pointing out the level vs edge interaction. If we
call that a userspace bug, I can just drop this. Thanks
On 09/05/2012 06:09 PM, Michael S. Tsirkin wrote:
On Wed, Sep 05, 2012 at 05:51:53PM +0300, Michael S. Tsirkin wrote:
On Wed, Sep 05, 2012 at 05:35:43PM +0300, Avi Kivity wrote:
On 08/22/2012 03:41 AM, Michael S. Tsirkin wrote:
I assumed you were pointing out the level vs edge
On 09/05/2012 06:07 PM, Michael S. Tsirkin wrote:
On Wed, Sep 05, 2012 at 05:46:17PM +0300, Avi Kivity wrote:
On 08/21/2012 10:29 PM, Alex Williamson wrote:
KVM_IRQFD currently uses the reserved KVM_USERSPACE_IRQ_SOURCE_ID
which is also shared with userspace injection methods like
On 09/05/2012 06:13 PM, Michael S. Tsirkin wrote:
On Wed, Sep 05, 2012 at 05:59:46PM +0300, Avi Kivity wrote:
On 09/05/2012 05:51 PM, Michael S. Tsirkin wrote:
On Wed, Sep 05, 2012 at 05:35:43PM +0300, Avi Kivity wrote:
On 08/22/2012 03:41 AM, Michael S. Tsirkin wrote:
I assumed you
On 09/05/2012 06:28 PM, Michael S. Tsirkin wrote:
gsi 3 is configured as edge in the ioapic. It has (unusually) two
inputs: one driven by userspace, the other by irqfd.
cpu 0cpu 1
-
irqfd: set to 1
ioapic: recognize
On 09/04/2012 07:34 PM, Avi Kivity wrote:
> On 08/31/2012 12:56 PM, Michael S. Tsirkin wrote:
>> On Fri, Aug 31, 2012 at 11:36:07AM +0200, Sasha Levin wrote:
>>> On 08/30/2012 03:38 PM, Michael S. Tsirkin wrote:
>>> >> +static unsigned int indirect_alloc_thresh
On 08/31/2012 12:56 PM, Michael S. Tsirkin wrote:
> On Fri, Aug 31, 2012 at 11:36:07AM +0200, Sasha Levin wrote:
>> On 08/30/2012 03:38 PM, Michael S. Tsirkin wrote:
>> >> +static unsigned int indirect_alloc_thresh = 16;
>> > Why 16? Please make is MAX_SG + 1 this makes some sense.
>>
>>
On 09/04/2012 03:09 PM, Avi Kivity wrote:
> On 08/30/2012 02:30 AM, Mathias Krause wrote:
>> As the the compiler ensures that the memory operand is always aligned
>> to a 16 byte memory location,
>
> I'm not sure it does. Is V4SI aligned? Do we use alignof() to
>
On 08/30/2012 02:30 AM, Mathias Krause wrote:
> As the the compiler ensures that the memory operand is always aligned
> to a 16 byte memory location,
I'm not sure it does. Is V4SI aligned? Do we use alignof() to
propagate the alignment to the vcpu allocation code?
> use the aligned variant of
On 08/30/2012 02:30 AM, Mathias Krause wrote:
As the the compiler ensures that the memory operand is always aligned
to a 16 byte memory location,
I'm not sure it does. Is V4SI aligned? Do we use alignof() to
propagate the alignment to the vcpu allocation code?
use the aligned variant of
On 09/04/2012 03:09 PM, Avi Kivity wrote:
On 08/30/2012 02:30 AM, Mathias Krause wrote:
As the the compiler ensures that the memory operand is always aligned
to a 16 byte memory location,
I'm not sure it does. Is V4SI aligned? Do we use alignof() to
propagate the alignment to the vcpu
On 08/31/2012 12:56 PM, Michael S. Tsirkin wrote:
On Fri, Aug 31, 2012 at 11:36:07AM +0200, Sasha Levin wrote:
On 08/30/2012 03:38 PM, Michael S. Tsirkin wrote:
+static unsigned int indirect_alloc_thresh = 16;
Why 16? Please make is MAX_SG + 1 this makes some sense.
Wouldn't MAX_SG mean
On 09/04/2012 07:34 PM, Avi Kivity wrote:
On 08/31/2012 12:56 PM, Michael S. Tsirkin wrote:
On Fri, Aug 31, 2012 at 11:36:07AM +0200, Sasha Levin wrote:
On 08/30/2012 03:38 PM, Michael S. Tsirkin wrote:
+static unsigned int indirect_alloc_thresh = 16;
Why 16? Please make is MAX_SG + 1
On 06/26/2012 11:32 PM, Frank Swiderski wrote:
> This implementation of a virtio balloon driver uses the page cache to
> "store" pages that have been released to the host. The communication
> (outside of target counts) is one way--the guest notifies the host when
> it adds a page to the page
On 08/27/2012 12:51 PM, Dong Hao wrote:
> From: Xiao Guangrong
>
> Exporting KVM exit information to userspace to be consumed by perf.
>
> [ Dong Hao : rebase it on acme's git tree ]
> Signed-off-by: Xiao Guangrong
> Signed-off-by: Dong Hao
> ---
> arch/x86/include/asm/kvm_host.h | 36
On 08/27/2012 12:51 PM, Dong Hao wrote:
> From: Xiao Guangrong
>
> 'perf kvm stat record/report' will use kvm_exit and kvm_mmio(read...) to
> calculate mmio read emulated time for the old kernel, in order to trace
> mmio read event more exactly, we add kvm_mmio_begin to trace the time when
>
301 - 400 of 3216 matches
Mail list logo
