On 11/08/2015 01:49 PM, Joerg Roedel wrote:
On Sun, Nov 08, 2015 at 12:37:47PM +0200, Michael S. Tsirkin wrote:
I have no problem with that. For example, can we teach
the DMA API on intel x86 to use PT for virtio by default?
That would allow merging Andy's patches with
full compatibility with ol
On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote:
>
>
> I tried to generate a DMAR table that excludes some devices from
> IOMMU translation, however it does not help.
>
> The reason is, as far as I understand, that Linux kernel does
> not allow any device being outside an IOMMU scope i
On Fri, 2015-11-20 at 10:21 +0200, Michael S. Tsirkin wrote:
>
> David, there are two things a hypervisor needs to tell the guest.
> 1. The actual device is behind an IOMMU. This is what you
> are suggesting we use DMAR for.
> 2. Using IOMMU from kernel (as opposed to from userspace with VFIO)
On 11/22/2015 05:54 PM, David Woodhouse wrote:
On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote:
I tried to generate a DMAR table that excludes some devices from
IOMMU translation, however it does not help.
The reason is, as far as I understand, that Linux kernel does
not allow any d
On Sun, Nov 22, 2015 at 03:58:28PM +, David Woodhouse wrote:
> On Fri, 2015-11-20 at 10:21 +0200, Michael S. Tsirkin wrote:
> >
> > David, there are two things a hypervisor needs to tell the guest.
> > 1. The actual device is behind an IOMMU. This is what you
> > are suggesting we use DMAR
On Sun, Nov 22, 2015 at 03:54:21PM +, David Woodhouse wrote:
> On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote:
> >
> >
> > I tried to generate a DMAR table that excludes some devices from
> > IOMMU translation, however it does not help.
> >
> > The reason is, as far as I understan
> There's that, and there's an "I care about security, but
> do not want to burn up cycles on fake protections that
> do not work" case.
It would seem to make most sense for this use case simply *not* to expose
virtio devices to guests as being behind an IOMMU at all. Sure, there are
esoteric us
> There's that, and there's an "I care about security, but
> do not want to burn up cycles on fake protections that
> do not work" case.
It would seem to make most sense for this use case simply *not* to expose
virtio devices to guests as being behind an IOMMU at all. Sure, there are
esoteric us
https://bugzilla.kernel.org/show_bug.cgi?id=107561
Paolo Bonzini changed:
What|Removed |Added
CC||bonz...@gnu.org
--- Comment #5 from Paol
https://bugzilla.kernel.org/show_bug.cgi?id=107561
--- Comment #6 from Paolo Bonzini ---
Ah, the traces are huge. You can xz them and send them through private email.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the lin
https://bugzilla.kernel.org/show_bug.cgi?id=107561
Paolo Bonzini changed:
What|Removed |Added
CC||tajj...@gmail.com
--- Comment #7 from Pa
https://bugzilla.kernel.org/show_bug.cgi?id=107921
Paolo Bonzini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Fri, 20 Nov 2015 09:11:45 +0100
Thomas Huth wrote:
> In the old DABR register, the BT (Breakpoint Translation) bit
> is bit number 61. In the new DAWRX register, the WT (Watchpoint
> Translation) bit is bit number 59. So to move the DABR-BT bit
> into the position of the DAWRX-WT bit, it has t
On Sun, Nov 22, 2015 at 10:21:34PM -, David Woodhouse wrote:
>
>
> > There's that, and there's an "I care about security, but
> > do not want to burn up cycles on fake protections that
> > do not work" case.
>
> It would seem to make most sense for this use case simply *not* to expose
> virt
14 matches
Mail list logo
