On 2011-05-26 23:19, André Weidemann wrote:
> On 27.05.2011 21:50, André Weidemann wrote:
>> On 27.05.2011 21:40, André Weidemann wrote:
>>
>>> If I am not mistaken then the graphics card needs 2 bars, one with 256MB
>>> and one with 128K. The sound card then needs 1 bar with 16K of PCI
>>> memory.
On 2011-05-10 10:02, BrillyWu wrote:
> From: BrillyWu
>
> When KVM is running on VIA CPU with host cpu's model, the
> feautures of VIA CPU will be passed into kvm guest by calling
> the CPUID instruction for Centaur.
>
> Signed-off-by: BrillyWu
> Signed-off-by: KaryJin
> ---
> target-i386/cpu.h
Document KVM_IOEVENTFD that can be used to receive
notifications of PIO/MMIO events without triggering
an exit.
Cc: Avi Kivity
Cc: Marcelo Tosatti
Signed-off-by: Sasha Levin
---
Documentation/virtual/kvm/api.txt | 30 ++
1 files changed, 30 insertions(+), 0 deleti
* Sasha Levin wrote:
> So the basic plan here is to allocate a futex(?) for each VCPU
> thread, and have the writer thread lock all futexes when it needs
> to write?
>
> If we assume we only have one writer thread, it can stay pretty
> simple.
We can use an even simpler and more scalable me
On 2011-05-10 10:02, BrillyWu wrote:
> From: BrillyWu
>
> When KVM is running on VIA CPU with host cpu's model, the
> feautures of VIA CPU will be passed into kvm guest by calling
> the CPUID instruction for Centaur.
>
> Signed-off-by: BrillyWu
> Signed-off-by: KaryJin
...
> @@ -855,6 +870,8 @
On Sat, May 28, 2011 at 05:24:08PM +0200, Ingo Molnar wrote:
>
> * Sasha Levin wrote:
>
> > So the basic plan here is to allocate a futex(?) for each VCPU
> > thread, and have the writer thread lock all futexes when it needs
> > to write?
> >
> > If we assume we only have one writer thread, i
On Thu, 2011-05-26 at 13:31 -0700, Shirley Ma wrote:
> On Thu, 2011-05-26 at 23:28 +0300, Michael S. Tsirkin wrote:
> > On Thu, May 26, 2011 at 01:00:20PM -0700, Shirley Ma wrote:
> > > 3. Add sleep in vhost shutting down instead of busy-wait for
> > outstanding
> > >DMAs.
> >
> > I still thin
On 05/27/2011 02:07 PM, Ingo Molnar wrote:
* Ingo Molnar wrote:
> > This code is very much tied with the kernel scheduler. [...]
>
> It would not be particularly complex to enable user-space to
> request a callback on context switch events.
>
> I was thinking on and off about allowing perf
On 05/27/2011 04:31 PM, Ingo Molnar wrote:
One furthr optimization would be possible: in case you think we can
write the signal handler in assembly or build it with gcc flags that
does not use SSE we might also add a 'lightweight signal handler'
kind of flag to the kernel, which does not save FPU
* Avi Kivity wrote:
> > So if you set a notification signal via fcntl(F_SETOWN) on the
> > scheduler context switch event fd, the user-space RCU code will
> > get a signal on every context switch.
>
> Context switches are completely uninteresting for userspace rcu:
>
> rcu_read_lock();
>
Hi,
On 28.05.2011 10:18, Jan Kiszka wrote:
On 2011-05-26 23:19, André Weidemann wrote:
On 27.05.2011 21:50, André Weidemann wrote:
On 27.05.2011 21:40, André Weidemann wrote:
If I am not mistaken then the graphics card needs 2 bars, one with 256MB
and one with 128K. The sound card then needs
This patchset add supports for TX zero-copy between guest and host
kernel through vhost. It significantly reduces CPU utilization on the
local host on which the guest is located (It reduced about 50% CPU usage
for single stream test on the host, while 4K message size BW has
increased about 50%). Th
include/net/sock.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index f2046e4..2229bd1 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -563,6 +563,7 @@ enum sock_flags {
SOCK_TIMESTAMPING_SYS_HARDWARE, /* %SOF_
This patch adds userspace buffers support in skb shared info. A new
struct skb_ubuf_info is needed to maintain the userspace buffers
argument and index, a callback is used to notify userspace to release
the buffers once lower device has done DMA (Last reference to that skb
has gone).
If there is
Hello Michael,
In order to use wait for completion in shutting down, seems to me
another work thread is needed to call vhost_zerocopy_add_used, it seems
too much work to address a minor issue here. Do we really need it?
Right now, the approach I am using is to ignore outstanding userspace
buffers
Only when buffer size is greater than or equal PAGE_SIZE, macvtap
enables zero-copy.
Signed-off-by: Shirley Ma
---
drivers/net/macvtap.c | 131
1 files changed, 120 insertions(+), 11 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net
On Sat, 2011-05-28 at 12:15 -0700, Shirley Ma wrote:
> include/net/sock.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index f2046e4..2229bd1 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -563,6 +563,7 @
On Sat, 2011-05-28 at 17:24 +0200, Ingo Molnar wrote:
> * Sasha Levin wrote:
>
> > So the basic plan here is to allocate a futex(?) for each VCPU
> > thread, and have the writer thread lock all futexes when it needs
> > to write?
> >
> > If we assume we only have one writer thread, it can stay
On Thu, May 26, 2011 at 12:58:23PM +0930, Rusty Russell wrote:
> On Wed, 25 May 2011 09:07:59 +0300, "Michael S. Tsirkin"
> wrote:
> > On Wed, May 25, 2011 at 11:05:04AM +0930, Rusty Russell wrote:
> > Hmm I'm not sure I got it, need to think about this.
> > I'd like to go back and document how m
> > + best = kvm_find_cpuid_entry(vcpu, 7, 0);
> > + if (best&& (best->ebx& bit(X86_FEATURE_SMEP))) {
> > + if (boot_cpu_has(X86_FEATURE_SMEP))
> > + vcpu->arch.cr4_reserved_bits&=
> > + ~((unsigned long)X86_CR4_SMEP);
>
> Fails if cpuid
On 05/28/2011 09:32 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
> > So if you set a notification signal via fcntl(F_SETOWN) on the
> > scheduler context switch event fd, the user-space RCU code will
> > get a signal on every context switch.
>
> Context switches are completely uninterestin
On 05/29/2011 08:16 AM, Li, Xin wrote:
>
> > + else
> > + best->ebx&= ~(bit(X86_FEATURE_SMEP));
>
> Not needed - x86.c already masks unsupported features.
Should KVM still support guest SMEP when host disables it thru nosmep?
No. We treat nosmep as "no smep fo
On 05/28/2011 10:45 PM, Sasha Levin wrote:
On Sat, 2011-05-28 at 17:24 +0200, Ingo Molnar wrote:
> * Sasha Levin wrote:
>
> > So the basic plan here is to allocate a futex(?) for each VCPU
> > thread, and have the writer thread lock all futexes when it needs
> > to write?
> >
> > If we
23 matches
Mail list logo
