On Mon, Dec 07, 2009 at 06:33:35PM +0100, Joanna Rutkowska wrote:
Avi Kivity wrote:
On 12/07/2009 07:15 PM, Joanna Rutkowska wrote:
But the difference is that in case of Xen one can *easily* move the
backends to small unprivileged VMs. In that case it doesn't matter the
code is in
Hello,
I have the following questions regarding the KVM architecture. I looked
at the slides available at linux-kvm.org, but didn't find definitive
answers. I'm also interested to learn if given feature is or is not
planned for the near future.
The questions follow:
1) Do you have any support
On 12/07/2009 03:05 PM, Joanna Rutkowska wrote:
Hello,
I have the following questions regarding the KVM architecture. I looked
at the slides available at linux-kvm.org, but didn't find definitive
answers. I'm also interested to learn if given feature is or is not
planned for the near future.
Avi Kivity wrote:
1) Do you have any support for para-virtualized VMs?
Yes, for example, we support paravirtualized timers and mmu for Linux.
These are fairly minimal compared to Xen's pv domains.
Can I run a regular Linux as PV-guest? Specifically, can I get rid of
qemu totally,
On 12/07/2009 03:30 PM, Joanna Rutkowska wrote:
Avi Kivity wrote:
1) Do you have any support for para-virtualized VMs?
Yes, for example, we support paravirtualized timers and mmu for Linux.
These are fairly minimal compared to Xen's pv domains.
Can I run a regular Linux as
Avi Kivity wrote:
On 12/07/2009 03:05 PM, Joanna Rutkowska wrote:
In particular, is
it possible to move the qemu from the host to one of the VMs? Perhaps to
have a separate copy of qemu for each VM? (ala Xen's stub-domains)
It should be fairly easy to place qemu in a guest. You would
On 12/07/2009 03:55 PM, Joanna Rutkowska wrote:
It should be fairly easy to place qemu in a guest. You would leave a
simple program on the host to communicate with kvm and pass any data
written by the guest to qemu running in another guest, and feed any
replies back to the guest.
But
Avi Kivity wrote:
On 12/07/2009 03:30 PM, Joanna Rutkowska wrote:
Avi Kivity wrote:
1) Do you have any support for para-virtualized VMs?
Yes, for example, we support paravirtualized timers and mmu for Linux.
These are fairly minimal compared to Xen's pv domains.
Can I
On 12/07/2009 04:06 PM, Joanna Rutkowska wrote:
Can you point to a document/source file that would list all the possible
interfaces between VM and the host? I.e. all the VMX handlers, and all
the hypercalls (PV interfaces).
arch/x86/kvm/vmx.c is the entry point for all interaction, but it
Avi Kivity wrote:
No. Paravirtualization just augments the standard hardware interface,
it doesn't replace it as in Xen.
NB, unlike Xen, we can (and do) run qemu as non-root. Things like
RHEV-H and oVirt constrain the qemu process with SELinux.
Also, you can use qemu to provide the
Joanna Rutkowska wrote:
Avi Kivity wrote:
On 12/07/2009 03:05 PM, Joanna Rutkowska wrote:
In particular, is
it possible to move the qemu from the host to one of the VMs? Perhaps to
have a separate copy of qemu for each VM? (ala Xen's stub-domains)
It should be fairly easy
Anthony Liguori wrote:
Avi Kivity wrote:
No. Paravirtualization just augments the standard hardware interface,
it doesn't replace it as in Xen.
NB, unlike Xen, we can (and do) run qemu as non-root. Things like
RHEV-H and oVirt constrain the qemu process with SELinux.
On Xen you can get
On 12/07/2009 07:09 PM, Joanna Rutkowska wrote:
Also, you can use qemu to provide the backends to a Xen PV guest (see -M
xenpv). The effect is that you are moving that privileged code from the
kernel (netback/blkback) to userspace (qemu -M xenpv).
In general, KVM tends to keep code in
Avi Kivity wrote:
On 12/07/2009 07:09 PM, Joanna Rutkowska wrote:
Also, you can use qemu to provide the backends to a Xen PV guest (see -M
xenpv). The effect is that you are moving that privileged code from the
kernel (netback/blkback) to userspace (qemu -M xenpv).
In general, KVM tends to
On 12/07/2009 07:15 PM, Joanna Rutkowska wrote:
But the difference is that in case of Xen one can *easily* move the
backends to small unprivileged VMs. In that case it doesn't matter the
code is in kernel mode, it's still only in an unprivileged domain.
They're not really
Joanna Rutkowska wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
No. Paravirtualization just augments the standard hardware interface,
it doesn't replace it as in Xen.
NB, unlike Xen, we can (and do) run qemu as non-root. Things like
RHEV-H and oVirt constrain the qemu
Avi Kivity wrote:
On 12/07/2009 07:15 PM, Joanna Rutkowska wrote:
But the difference is that in case of Xen one can *easily* move the
backends to small unprivileged VMs. In that case it doesn't matter the
code is in kernel mode, it's still only in an unprivileged domain.
They're
Joanna Rutkowska wrote:
Avi Kivity wrote:
On 12/07/2009 07:09 PM, Joanna Rutkowska wrote:
Also, you can use qemu to provide the backends to a Xen PV guest (see -M
xenpv). The effect is that you are moving that privileged code from the
kernel (netback/blkback) to userspace (qemu -M
Anthony Liguori wrote:
Joanna Rutkowska wrote:
Avi Kivity wrote:
On 12/07/2009 07:09 PM, Joanna Rutkowska wrote:
Also, you can use qemu to provide the backends to a Xen PV guest
(see -M
xenpv). The effect is that you are moving that privileged code
from the
kernel
On Mon, Dec 07, 2009 at 06:09:55PM +0100, Joanna Rutkowska wrote:
Also, SELinux seems to me like a step into the wrong direction. It not
only adds complexity to the already-too-complex kernel, but requires
complex configuration. See e.g. this paper[1] for a nice example of how
to escape
Anthony Liguori wrote:
Joanna Rutkowska wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
No. Paravirtualization just augments the standard hardware interface,
it doesn't replace it as in Xen.
NB, unlike Xen, we can (and do) run qemu as non-root. Things like
RHEV-H and oVirt
On 12/07/2009 07:33 PM, Joanna Rutkowska wrote:
AFAIK VT-d is only supported in Xen for fully virtualized guests. Maybe
it changed while I wasn't watching, though.
Negative. VT-d can be used to contain PV DomUs as well. We actually
verified it.
Ah, good for them.
It can use
Muli Ben-Yehuda wrote:
On Mon, Dec 07, 2009 at 11:38:52AM -0600, Anthony Liguori wrote:
I'm skeptical that VT-d in its current form provides protection
against a malicious guest. The first problem is interrupt delivery.
I don't think any hypervisor has really put much thought into
23 matches
Mail list logo
