On Thu, Aug 29, 2013 at 03:55:20PM -0700, Aaron Fabbri wrote:
Has anyone considered a paravirt approach? That is:
Guest kernel: Write a new IOMMU API back end which does KVM hypercalls.
Exposes VFIO to guest user processes (nested VMs) as usual.
Host kernel: KVM does things like
Has anyone considered a paravirt approach? That is:
Guest kernel: Write a new IOMMU API back end which does KVM hypercalls.
Exposes VFIO to guest user processes (nested VMs) as usual.
Host kernel: KVM does things like collapse {guest_va - guest_pa -
host_pa} mappings to {guest_va - host_pa},
Hi,
I want to get the following setup, but don't know how (or if it's even
possible):
* A guest VM with two AHCI controllers, with one device each. One of the AHCI
controllers provides the VM's disk (system), while the other provides
another disk (nested) and uses a different emulation
On 2013-08-28 16:28, Lluís Vilanova wrote:
Hi,
I want to get the following setup, but don't know how (or if it's even
possible):
* A guest VM with two AHCI controllers, with one device each. One of the AHCI
controllers provides the VM's disk (system), while the other provides
another
Jan Kiszka writes:
[...]
Is it possible to give a nested guest direct access to a device on the guest?
(more specifically, an AHCI controller).
Nope, we are lacking support for emulating or (securely) forwarding
VT-d/IOMMU features to the first level guest. Would be cool to have,
just not
On 2013-08-28 20:12, Lluís Vilanova wrote:
Jan Kiszka writes:
[...]
Is it possible to give a nested guest direct access to a device on the
guest?
(more specifically, an AHCI controller).
Nope, we are lacking support for emulating or (securely) forwarding
VT-d/IOMMU features to the first
Jan Kiszka writes:
On 2013-08-28 20:12, Lluís Vilanova wrote:
Jan Kiszka writes:
[...]
Is it possible to give a nested guest direct access to a device on the
guest?
(more specifically, an AHCI controller).
Nope, we are lacking support for emulating or (securely) forwarding
VT-d/IOMMU
