On 29/07/2015 02:47, Andy Lutomirski wrote:
If new kernels ignore the IOMMU for devices that don't set the flag
and there are physical devices that already exist and don't set the
flag, then those devices won't work reliably on most modern
non-virtual platforms, PPC included.
Are
On 2015-07-29 01:21, Benjamin Herrenschmidt wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
New QEMU
always advertises this feature flag. If iommu=on, QEMU's virtio
devices refuse to work unless the driver acknowledges the flag.
This should be configurable.
On 2015-07-29 10:17, Paolo Bonzini wrote:
On 29/07/2015 02:47, Andy Lutomirski wrote:
If new kernels ignore the IOMMU for devices that don't set the flag
and there are physical devices that already exist and don't set the
flag, then those devices won't work reliably on most modern
On Wed, 2015-07-29 at 10:17 +0200, Paolo Bonzini wrote:
On 29/07/2015 02:47, Andy Lutomirski wrote:
If new kernels ignore the IOMMU for devices that don't set the flag
and there are physical devices that already exist and don't set the
flag, then those devices won't work reliably on
Am 28.07.2015 um 03:08 schrieb Andy Lutomirski:
On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net wrote:
This fixes virtio on Xen guests as well as on any other platform
that uses virtio_pci on which physical addresses don't match bus
addresses.
This can be tested with:
On 28/07/2015 03:08, Andy Lutomirski wrote:
On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net wrote:
This fixes virtio on Xen guests as well as on any other platform
that uses virtio_pci on which physical addresses don't match bus
addresses.
This can be tested with:
On Tue, Jul 28, 2015 at 4:21 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support.
New kernels acknowledge that flag on any device that
On Tue, 2015-07-28 at 17:47 -0700, Andy Lutomirski wrote:
Yes, virtio flag. I dislike having a virtio flag at all, but so far
no one has come up with any better ideas. If there was a reliable,
cross-platform mechanism for per-device PCI bus properties, I'd be all
for using that instead.
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support.
New kernels acknowledge that flag on any device that advertises it.
New kernels always respect the IOMMU (except on PowerPC).
Why ? I disagree,
On Tue, 2015-07-28 at 16:33 -0700, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 4:21 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support.
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support.
New kernels acknowledge that flag on any device that advertises it.
New kernels always respect the IOMMU (except on PowerPC). New kernels
optionally refuse to talk to devices that don't have that feature flag
On Tue, Jul 28, 2015 at 5:36 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 16:33 -0700, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 4:21 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
On 2015-07-28 15:06, Michael S. Tsirkin wrote:
On Tue, Jul 28, 2015 at 02:46:20PM +0200, Paolo Bonzini wrote:
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote:
That is an experimental feature (it's x-iommu), so it can change.
The plan was:
- for PPC, virtio never honors IOMMU
- for
On Tue, Jul 28, 2015 at 02:46:20PM +0200, Paolo Bonzini wrote:
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote:
That is an experimental feature (it's x-iommu), so it can change.
The plan was:
- for PPC, virtio never honors IOMMU
- for non-PPC, either have virtio
On Jul 28, 2015 6:11 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 15:06, Michael S. Tsirkin wrote:
On Tue, Jul 28, 2015 at 02:46:20PM +0200, Paolo Bonzini wrote:
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote:
That is an experimental feature (it's x-iommu), so it can
On Tue, 2015-07-28 at 10:16 +0200, Paolo Bonzini wrote:
On 28/07/2015 03:08, Andy Lutomirski wrote:
On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net
wrote:
This fixes virtio on Xen guests as well as on any other platform
that uses virtio_pci on which physical
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote:
That is an experimental feature (it's x-iommu), so it can change.
The plan was:
- for PPC, virtio never honors IOMMU
- for non-PPC, either have virtio always honor IOMMU, or enforce that
virtio is not under IOMMU.
I
On 28/07/2015 15:11, Jan Kiszka wrote:
This doesn't matter much, since the only guests that implement an IOMMU
in QEMU are (afaik) PPC and x86, and x86 does not yet promise any kind
of stability.
Hmm I think Jan (cc) said it was already used out there.
Yes, no known issues with
On Tue, Jul 28, 2015 at 9:44 AM, Jan Kiszka jan.kis...@siemens.com wrote:
The ability to have virtio on systems with IOMMU in place makes testing
much more efficient for us. Ideally, we would have it in non-identity
mapping scenarios as well, e.g. to start secondary Linux instances in
the test
On 28/07/2015 18:42, Jan Kiszka wrote:
On the other hand interrupt remapping is absolutely necessary for
production use, hence my point that x86 does not promise API stability.
Well, we currently implement the features that the Q35 used to expose.
Adding interrupt remapping will require
On 28/07/2015 19:19, Jan Kiszka wrote:
On 2015-07-28 19:15, Paolo Bonzini wrote:
On 28/07/2015 18:42, Jan Kiszka wrote:
On the other hand interrupt remapping is absolutely necessary for
production use, hence my point that x86 does not promise API stability.
Well, we currently implement
On 2015-07-28 19:15, Paolo Bonzini wrote:
On 28/07/2015 18:42, Jan Kiszka wrote:
On the other hand interrupt remapping is absolutely necessary for
production use, hence my point that x86 does not promise API stability.
Well, we currently implement the features that the Q35 used to expose.
On 2015-07-28 18:36, Paolo Bonzini wrote:
On 28/07/2015 15:11, Jan Kiszka wrote:
This doesn't matter much, since the only guests that implement an IOMMU
in QEMU are (afaik) PPC and x86, and x86 does not yet promise any kind
of stability.
Hmm I think Jan (cc) said it was already used out
On 2015-07-28 19:10, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 9:44 AM, Jan Kiszka jan.kis...@siemens.com wrote:
The ability to have virtio on systems with IOMMU in place makes testing
much more efficient for us. Ideally, we would have it in non-identity
mapping scenarios as well, e.g. to
On 2015-07-28 18:11, Andy Lutomirski wrote:
On Jul 28, 2015 6:11 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 15:06, Michael S. Tsirkin wrote:
On Tue, Jul 28, 2015 at 02:46:20PM +0200, Paolo Bonzini wrote:
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote:
That is an
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble is that this is really a property of the bus and not of
the device. If you build a virtio device that physically plugs
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble is that this is really a property of the bus and not of
the device. If you build a virtio device that physically plugs into a
PCIe slot, the device has no concept
On Tue, Jul 28, 2015 at 12:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble is that this is really a property of the bus
On 2015-07-28 21:24, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 12:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 19:10, Andy Lutomirski wrote:
The trouble
On Tue, Jul 28, 2015 at 12:33 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 21:24, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 12:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2015-07-28 20:22, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:17 AM, Jan Kiszka
On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net wrote:
This fixes virtio on Xen guests as well as on any other platform
that uses virtio_pci on which physical addresses don't match bus
addresses.
This can be tested with:
virtme-run --xen xen --kimg
On Fri, Sep 05, 2014 at 12:01:33PM +0930, Rusty Russell wrote:
Andy Lutomirski l...@amacapital.net writes:
On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
On 09/04/2014 10:57 PM, Andy Lutomirski wrote:
On Thu, Sep 4, 2014 at 7:31 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
There really
On Wed, Sep 10, 2014 at 8:36 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/04/2014 10:57 PM, Andy Lutomirski wrote:
There's a third option: try to make virtio-mmio work everywhere
(except s390), at least in the long run. This other benefits: it
makes minimal hypervisors simpler,
On 05/09/14 04:57, Andy Lutomirski wrote:
There's a third option: try to make virtio-mmio work everywhere
(except s390), at least in the long run. This other benefits: it
makes minimal hypervisors simpler, I think it'll get rid of the limits
on the number of virtio devices in a system. ARM
On Tue, 2014-09-02 at 16:11 -0700, Andy Lutomirski wrote:
I don't think so. I would argue that it's a straight-up bug for QEMU
to expose a physically-addressed virtio-pci device to the guest behind
an emulated IOMMU. QEMU may already be doing that on ppc64, but it
isn't on x86_64 or arm
On Wed, 2014-09-03 at 09:47 +0200, Paolo Bonzini wrote:
IOMMU support for x86 is going to go in this week.
But won't that break virtio on x86 ? Or will virtio continue bypassing
it ? IE, the guest side virtio doesn't expect an IOMMU and doesn't call
the dma mappings ops.
However, it is and
On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote:
But there aren't any ACPI systems with both virtio-pci and IOMMUs,
right? So we could say that, henceforth, ACPI systems must declare
whether virtio-pci devices live behind IOMMUs without breaking
backward compatibility.
I don't know
On Tue, 2014-09-02 at 17:32 -0700, Andy Lutomirski wrote:
I agree *except* that implementing it will be a real PITA and (I
think) can't be done without changing code in arch/. My patches plus
an ifdef powerpc will be functionally equivalent, just uglier.
So for powerpc, it's a 2 liner
Andy Lutomirski l...@amacapital.net writes:
On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
figments of a hypervisor's imagination [1].
Hi Andy,
As
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Sep 03, 2014 at 04:12:01PM +0930, Rusty Russell wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
figments of a hypervisor's imagination [1].
Hi Andy,
As
On Thu, Sep 4, 2014 at 7:31 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon
On Thu, Sep 4, 2014 at 7:32 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Sep 03, 2014 at 04:12:01PM +0930, Rusty Russell wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
On Fri, 2014-09-05 at 12:01 +0930, Rusty Russell wrote:
If the answers are both yes, then x86 is going to be able to use
virtio+IOMMU, so PPC looks like the odd one out.
Well, yes and no ... ppc will be able to do that too, it's just
pointless and will suck performances.
Additionally, it will
On Thu, 2014-09-04 at 19:57 -0700, Andy Lutomirski wrote:
There's a third option: try to make virtio-mmio work everywhere
(except s390), at least in the long run. This other benefits: it
makes minimal hypervisors simpler, I think it'll get rid of the limits
on the number of virtio devices in
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
figments of a hypervisor's imagination [1].
Hi Andy,
As you're discovering, there's a reason no one has done the DMA
API before.
So the problem is that ppc64's IOMMU is a
Il 03/09/2014 01:20, Benjamin Herrenschmidt ha scritto:
I wouldn't be so certain, as I said, the way virtio is implemented in
qemu bypass the DMA layer which is where IOMMUs sit. The fact that
currently x86 doesn't put an IOMMU there is not even garanteed, is it ?
What happens if you try to
Il 03/09/2014 02:25, Benjamin Herrenschmidt ha scritto:
But there aren't any ACPI systems with both virtio-pci and IOMMUs,
right? So we could say that, henceforth, ACPI systems must declare
whether virtio-pci devices live behind IOMMUs without breaking
backward compatibility.
I don't
On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
figments of a hypervisor's imagination [1].
Hi Andy,
As you're discovering, there's a reason no one
On Wed, Sep 3, 2014 at 12:47 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 02:25, Benjamin Herrenschmidt ha scritto:
But there aren't any ACPI systems with both virtio-pci and IOMMUs,
right? So we could say that, henceforth, ACPI systems must declare
whether virtio-pci devices
Il 03/09/2014 09:52, Andy Lutomirski ha scritto:
IOMMU support for x86 is going to go in this week.
Can you try to make sure that qemu-system-x86_64 -device iommu -device
virtio-balloon-pci (or whatever the syntax is) doesn't put the
virtio-pci device behind the IOMMU? Because, if it does,
Il 03/09/2014 10:05, Benjamin Herrenschmidt ha scritto:
On Wed, 2014-09-03 at 09:47 +0200, Paolo Bonzini wrote:
IOMMU support for x86 is going to go in this week.
But won't that break virtio on x86 ? Or will virtio continue bypassing
it ? IE, the guest side virtio doesn't expect an IOMMU
On Wed, Sep 03, 2014 at 04:12:01PM +0930, Rusty Russell wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
figments of a hypervisor's imagination [1].
Hi Andy,
As you're discovering, there's a reason no one has
On Sep 3, 2014 5:11 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 10:05, Benjamin Herrenschmidt ha scritto:
On Wed, 2014-09-03 at 09:47 +0200, Paolo Bonzini wrote:
IOMMU support for x86 is going to go in this week.
But won't that break virtio on x86 ? Or will virtio
Il 03/09/2014 17:07, Andy Lutomirski ha scritto:
Yes, only for virtio---but for x86 I think it should be off by default,
even if that means virtio+IOMMU requires a new kernel.
Just to clarify: is it the direct-ram-access property? If so, I
think I might agree.
Yes.
Alternatively, could
On Wed, Sep 03, 2014 at 08:07:15AM -0700, Andy Lutomirski wrote:
On Sep 3, 2014 5:11 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 10:05, Benjamin Herrenschmidt ha scritto:
On Wed, 2014-09-03 at 09:47 +0200, Paolo Bonzini wrote:
IOMMU support for x86 is going to go in
On Wed, Sep 3, 2014 at 9:39 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Sep 03, 2014 at 08:07:15AM -0700, Andy Lutomirski wrote:
On Sep 3, 2014 5:11 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 10:05, Benjamin Herrenschmidt ha scritto:
On Wed, 2014-09-03 at 09:47
On Tue, Sep 2, 2014 at 5:43 PM, Benjamin Herrenschmidt b...@au1.ibm.com wrote:
On Tue, 2014-09-02 at 17:32 -0700, Andy Lutomirski wrote:
I agree *except* that implementing it will be a real PITA and (I
think) can't be done without changing code in arch/. My patches plus
an ifdef powerpc will
On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
On x86, at least, I doubt that we'll ever see a physically addressed
PCI virtio device for which ACPI advertises an IOMMU, since any sane
hypervisor will just not advertise an IOMMU for the virtio device.
But are there arm64 or PPC
On Wed, Sep 03, 2014 at 06:53:33AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
On x86, at least, I doubt that we'll ever see a physically addressed
PCI virtio device for which ACPI advertises an IOMMU, since any sane
hypervisor will just
On Tue, 2014-09-02 at 16:56 -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Sep 03, 2014 at 06:53:33AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
On x86, at least, I doubt that we'll ever see a physically addressed
PCI virtio device for
On Mon, Sep 01, 2014 at 10:55:29PM -0700, Andy Lutomirski wrote:
On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
Changes from v1:
- Using the DMA API is optional now. It would be nice to
On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
On x86, at least, I doubt that we'll ever see a physically addressed
PCI virtio device for which ACPI advertises an IOMMU, since any sane
hypervisor
On Tue, Sep 2, 2014 at 2:10 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 01, 2014 at 10:55:29PM -0700, Andy Lutomirski wrote:
On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
Changes
On Tue, 2014-09-02 at 14:37 -0700, Andy Lutomirski wrote:
Let's take a step back from from the implementation. What is a driver
for a virtio PCI device (i.e. a PCI device with vendor 0x1af4)
supposed to do on ppc64?
Today, it's supposed to send guest physical addresses. We can make that
On Tue, Sep 2, 2014 at 3:10 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2014-09-02 at 14:37 -0700, Andy Lutomirski wrote:
Let's take a step back from from the implementation. What is a driver
for a virtio PCI device (i.e. a PCI device with vendor 0x1af4)
supposed to do
On Tue, Sep 2, 2014 at 4:20 PM, Benjamin Herrenschmidt b...@au1.ibm.com wrote:
On Tue, 2014-09-02 at 16:11 -0700, Andy Lutomirski wrote:
I don't think so. I would argue that it's a straight-up bug for QEMU
to expose a physically-addressed virtio-pci device to the guest behind
an emulated
On Tue, Sep 2, 2014 at 5:25 PM, Benjamin Herrenschmidt b...@au1.ibm.com wrote:
On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote:
So here's an ugly proposal:
Step 1: Make virtio-pci use the DMA API only on x86. This will at
least fix Xen and people experimenting with virtio hardware
On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
Changes from v1:
- Using the DMA API is optional now. It would be nice to improve the
DMA API to the point that it could be used unconditionally, but s390
proves that we're not there yet.
- Includes patch 4, which fixes DMA
On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
Changes from v1:
- Using the DMA API is optional now. It would be nice to improve the
DMA API to the point that it could be used
70 matches
Mail list logo
