All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Sukanto Ghosh <sukanto.cse.iitb@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: comparisons with VMware and Xen
Date: Mon, 07 Jul 2008 15:39:29 -0500	[thread overview]
Message-ID: <48727F01.3080003@codemonkey.ws> (raw)
In-Reply-To: <a85e78f50807071309o25093532p83bc59176e1e4941@mail.gmail.com>

Sukanto Ghosh wrote:
> 1. Is the maximum no. of  vcpus in a particular guest limited to the
> no. of host cpus ? (I guess not)
>   

No.

> 2. Is there any attempt made to co-schedule all of a guest's vcpus, in
> order to avoid any spinlock holding problem ?
>   

Right now, no.  There is some discussion of gang scheduling within Linux 
but I don't know that it's going anywhere.  Recently, Jeremy 
Fitzhardinge posted some paravirtual spinlock patches for Linux that 
would at least allow for spinlock yielding.

> 3. Are there any means to do content-based page sharing between guests
> as VMware does ?
>   

Yes, KSM.

> 4. Does kvm makes any attempt to avoid TLB flushes while vm-exits and
> vm-entries ? like Xen makes a memory hole ?
> (my guess is that it doesn't needs to as kvm is mapped into a guest's
> address-space and the pages are protected with the help of linux vm.
> Am i right ? )
>   

A TLB flush is mandatory when using hardware virtualization support 
(even with Xen--you are thinking of Xen PV).  However, both Intel and 
AMD now support hardware TLB tagging which reduces the pain of this TLB 
flush.

> Slightly different ones,
>
> 5. How much useful is a balloon driver for kvm, which doesn't makes
> any hard partitions of available physical memory between the guests ?
> Shouldn't the linux VM's knowledge be superior in this case than the
> guest-vm's  ?
>   

Ballooning can be very useful when doing very large changes to the 
amount of guest memory.

> 6. What is coalesced mmio ?
>   

There are a number of times when a large number of MMIO writes occur 
back-to-back.  Think VGA planar updates, writes of a network packet to 
on-chip memory, etc.  Instead of passing each of these writes to 
userspace, we buffer a certain number of them and send a good bit of 
them down to QEMU.  The real win from this is making N-1 of the buffered 
writes into light-weight exits instead of heavy-weight exits.

Regards,

Anthony Liguori

>
>   


  parent reply	other threads:[~2008-07-07 20:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-07 20:09 comparisons with VMware and Xen Sukanto Ghosh
2008-07-07 20:13 ` Javier Guerra
2008-07-07 20:39 ` Anthony Liguori [this message]
2008-07-08  7:23   ` Sukanto Ghosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48727F01.3080003@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=sukanto.cse.iitb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.