search for: fsvo

...6 at 12:24:15PM -0700, Andy Lutomirski wrote: > On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > > the truth, and even legacy kernels ought to cope with that. > > FSVO 'ought to' where I suspect some of them will actually crash with a > > NULL pointer dereference if there's no "catch-all" DMAR unit in the > > tables, which puts it back into the same camp as ARM and Power. > > I think x86 may get a bit of a free pass here....

...6 at 12:24:15PM -0700, Andy Lutomirski wrote: > On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > > the truth, and even legacy kernels ought to cope with that. > > FSVO 'ought to' where I suspect some of them will actually crash with a > > NULL pointer dereference if there's no "catch-all" DMAR unit in the > > tables, which puts it back into the same camp as ARM and Power. > > I think x86 may get a bit of a free pass here....

...ki wrote: > >> On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > >> > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > >> > the truth, and even legacy kernels ought to cope with that. > >> > FSVO 'ought to' where I suspect some of them will actually crash with a > >> > NULL pointer dereference if there's no "catch-all" DMAR unit in the > >> > tables, which puts it back into the same camp as ARM and Power. > >> > >> I think x86...

...ki wrote: > >> On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > >> > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > >> > the truth, and even legacy kernels ought to cope with that. > >> > FSVO 'ought to' where I suspect some of them will actually crash with a > >> > NULL pointer dereference if there's no "catch-all" DMAR unit in the > >> > tables, which puts it back into the same camp as ARM and Power. > >> > >> I think x86...

...that certain devices aren't translated. So I suspect you probably can't enable virtio-behind-IOMMU in QEMU *ever* for those platforms as the default behaviour. For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell the truth, and even legacy kernels ought to cope with that. FSVO 'ought to' where I suspect some of them will actually crash with a NULL pointer dereference if there's no "catch-all" DMAR unit in the tables, which puts it back into the same camp as ARM and Power. > True but I think we should fix QEMU to shadow IOMMU > page tables fo...

...that certain devices aren't translated. So I suspect you probably can't enable virtio-behind-IOMMU in QEMU *ever* for those platforms as the default behaviour. For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell the truth, and even legacy kernels ought to cope with that. FSVO 'ought to' where I suspect some of them will actually crash with a NULL pointer dereference if there's no "catch-all" DMAR unit in the tables, which puts it back into the same camp as ARM and Power. > True but I think we should fix QEMU to shadow IOMMU > page tables fo...

On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > the truth, and even legacy kernels ought to cope with that. > FSVO 'ought to' where I suspect some of them will actually crash with a > NULL pointer dereference if there's no "catch-all" DMAR unit in the > tables, which puts it back into the same camp as ARM and Power. I think x86 may get a bit of a free pass here. AFAIK the QEMU IOMM...

...-0700, Andy Lutomirski wrote: >> On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: >> > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell >> > the truth, and even legacy kernels ought to cope with that. >> > FSVO 'ought to' where I suspect some of them will actually crash with a >> > NULL pointer dereference if there's no "catch-all" DMAR unit in the >> > tables, which puts it back into the same camp as ARM and Power. >> >> I think x86 may get a bit of a f...

...t; >> On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: >> >> > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell >> >> > the truth, and even legacy kernels ought to cope with that. >> >> > FSVO 'ought to' where I suspect some of them will actually crash with a >> >> > NULL pointer dereference if there's no "catch-all" DMAR unit in the >> >> > tables, which puts it back into the same camp as ARM and Power. >> >> >> >&...

...Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > >> >> > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > >> >> > the truth, and even legacy kernels ought to cope with that. > >> >> > FSVO 'ought to' where I suspect some of them will actually crash with a > >> >> > NULL pointer dereference if there's no "catch-all" DMAR unit in the > >> >> > tables, which puts it back into the same camp as ARM and Power. > >> >>...

...Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > >> >> > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > >> >> > the truth, and even legacy kernels ought to cope with that. > >> >> > FSVO 'ought to' where I suspect some of them will actually crash with a > >> >> > NULL pointer dereference if there's no "catch-all" DMAR unit in the > >> >> > tables, which puts it back into the same camp as ARM and Power. > >> >>...

...sses that they give us or they don't work at all (at least without iommu=pt), since the VT-D spec says: DMA requests processed through root-entries with present field Clear result in translation-fault. So I suspect the IOMMU_PLATFORM flag would have to stay off by default for a while. > FSVO 'ought to' where I suspect some of them will actually crash with a > NULL pointer dereference if there's no "catch-all" DMAR unit in the > tables, which puts it back into the same camp as ARM and Power. Right. That would also be an issue. > > > True but I th...

On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote: > > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > > its own operating system's IOMMU code is expected to be broken, and > > that the virtio driver should eschew the DMA API? > > No - it tells guest that e.g. the ACPI tables (or whatever the > equivalent is) do not match

On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote: > > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > > its own operating system's IOMMU code is expected to be broken, and > > that the virtio driver should eschew the DMA API? > > No - it tells guest that e.g. the ACPI tables (or whatever the > equivalent is) do not match

Hello, Let me first start by saying Shorewall is awesome, and I use it everywhere from single box firewall, to home network firewall, even to our corporate firewall. I am experiencing a problem getting my home firewall to work with my BroadVoice VoIP connection. I use the Sipura SPA-2100 ATA (Analog Telephone Adapter) that came with my BroadVoice account. This happened when I tried to replace

Hi, A number of FreeBSD users have displayed interest in the availability and testing of -STABLE and -CURRENT snapshot releases. I have been working on generating snapshots regularly, and now would like to announce their availability for those interested in testing. Please note, as always with the -STABLE and -CURRENT branches, these snapshots are not intended for production systems. The