search for: _cca

...changes are very small: several new registers, > > > > that's all. You want this for proper 64 bit dma mask anyway. > > > > > > As I've said, virtio 1 will have exactly the same issue unless we start > > > requiring firmware to advertise dma-coherent/_CCA for virtio-mmio > > > devices correctly. > > > > > > > OK I read up on _CCA in ACPI spec. It says: > > The _CCA object returns whether or not a bus-master device supports > > hardware managed cache coherency. Expected values are 0 to indicate it > >...

...changes are very small: several new registers, > > > > that's all. You want this for proper 64 bit dma mask anyway. > > > > > > As I've said, virtio 1 will have exactly the same issue unless we start > > > requiring firmware to advertise dma-coherent/_CCA for virtio-mmio > > > devices correctly. > > > > > > > OK I read up on _CCA in ACPI spec. It says: > > The _CCA object returns whether or not a bus-master device supports > > hardware managed cache coherency. Expected values are 0 to indicate it > >...

...plement virtio 1. > > For mmio the changes are very small: several new registers, > > that's all. You want this for proper 64 bit dma mask anyway. > > As I've said, virtio 1 will have exactly the same issue unless we start > requiring firmware to advertise dma-coherent/_CCA for virtio-mmio > devices correctly. > > Will OK I read up on _CCA in ACPI spec. It says: The _CCA object returns whether or not a bus-master device supports hardware managed cache coherency. Expected values are 0 to indicate it is not supported, and 1 to indicate that it is supported....

...plement virtio 1. > > For mmio the changes are very small: several new registers, > > that's all. You want this for proper 64 bit dma mask anyway. > > As I've said, virtio 1 will have exactly the same issue unless we start > requiring firmware to advertise dma-coherent/_CCA for virtio-mmio > devices correctly. > > Will OK I read up on _CCA in ACPI spec. It says: The _CCA object returns whether or not a bus-master device supports hardware managed cache coherency. Expected values are 0 to indicate it is not supported, and 1 to indicate that it is supported....

...when VIRTIO_F_IOMMU_PLATFORM > >>> is advertised by the device (which is what I suggested in my reply). > >> > >> I'm not ignoring that, but I need to understand that part a bit better. > >> I'll reply to that patch in a day or two after looking at how _CCA is > >> supposed to work. > > > > Thanks. I do think that whatever solution we come up with for virtio 1 > > should influence what we do for legacy. > > > >>> We can't detect the fastmodel, > >> > >> Surely, it puts a hardware id...

...when VIRTIO_F_IOMMU_PLATFORM > >>> is advertised by the device (which is what I suggested in my reply). > >> > >> I'm not ignoring that, but I need to understand that part a bit better. > >> I'll reply to that patch in a day or two after looking at how _CCA is > >> supposed to work. > > > > Thanks. I do think that whatever solution we come up with for virtio 1 > > should influence what we do for legacy. > > > >>> We can't detect the fastmodel, > >> > >> Surely, it puts a hardware id...

...t; > For mmio the changes are very small: several new registers, > > > that's all. You want this for proper 64 bit dma mask anyway. > > > > As I've said, virtio 1 will have exactly the same issue unless we start > > requiring firmware to advertise dma-coherent/_CCA for virtio-mmio > > devices correctly. > > > > OK I read up on _CCA in ACPI spec. It says: > The _CCA object returns whether or not a bus-master device supports > hardware managed cache coherency. Expected values are 0 to indicate it > is not supported, and 1 to indicat...

...; property is set/unset correctly when VIRTIO_F_IOMMU_PLATFORM > > is advertised by the device (which is what I suggested in my reply). > > I'm not ignoring that, but I need to understand that part a bit better. > I'll reply to that patch in a day or two after looking at how _CCA is > supposed to work. Thanks. I do think that whatever solution we come up with for virtio 1 should influence what we do for legacy. > > We can't detect the fastmodel, > > Surely, it puts a hardware id somewhere? I think you mean > fastmodel isn't always affected, righ...

...; property is set/unset correctly when VIRTIO_F_IOMMU_PLATFORM > > is advertised by the device (which is what I suggested in my reply). > > I'm not ignoring that, but I need to understand that part a bit better. > I'll reply to that patch in a day or two after looking at how _CCA is > supposed to work. Thanks. I do think that whatever solution we come up with for virtio 1 should influence what we do for legacy. > > We can't detect the fastmodel, > > Surely, it puts a hardware id somewhere? I think you mean > fastmodel isn't always affected, righ...

...ot; property is set/unset correctly when VIRTIO_F_IOMMU_PLATFORM >> is advertised by the device (which is what I suggested in my reply). > > I'm not ignoring that, but I need to understand that part a bit better. > I'll reply to that patch in a day or two after looking at how _CCA is > supposed to work. > >> We can't detect the fastmodel, > > Surely, it puts a hardware id somewhere? I think you mean > fastmodel isn't always affected, right? > >> but we could implicitly treat virtio-mmio >> devices as cache-coherent regardless of th...

...ot; property is set/unset correctly when VIRTIO_F_IOMMU_PLATFORM >> is advertised by the device (which is what I suggested in my reply). > > I'm not ignoring that, but I need to understand that part a bit better. > I'll reply to that patch in a day or two after looking at how _CCA is > supposed to work. > >> We can't detect the fastmodel, > > Surely, it puts a hardware id somewhere? I think you mean > fastmodel isn't always affected, right? > >> but we could implicitly treat virtio-mmio >> devices as cache-coherent regardless of th...

...when VIRTIO_F_IOMMU_PLATFORM > >>> is advertised by the device (which is what I suggested in my reply). > >> > >> I'm not ignoring that, but I need to understand that part a bit better. > >> I'll reply to that patch in a day or two after looking at how _CCA is > >> supposed to work. > > > > Thanks. I do think that whatever solution we come up with for virtio 1 > > should influence what we do for legacy. > > > >>> We can't detect the fastmodel, > >> > >> Surely, it puts a hardware id...

...when VIRTIO_F_IOMMU_PLATFORM > >>> is advertised by the device (which is what I suggested in my reply). > >> > >> I'm not ignoring that, but I need to understand that part a bit better. > >> I'll reply to that patch in a day or two after looking at how _CCA is > >> supposed to work. > > > > Thanks. I do think that whatever solution we come up with for virtio 1 > > should influence what we do for legacy. > > > >>> We can't detect the fastmodel, > >> > >> Surely, it puts a hardware id...

On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: > On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 7e38ed79c3fc..961af25b385c 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -20,6 +20,7 @@ > >

On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: > On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 7e38ed79c3fc..961af25b385c 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -20,6 +20,7 @@ > >

...lly push hosts to just implement virtio 1. > For mmio the changes are very small: several new registers, > that's all. You want this for proper 64 bit dma mask anyway. As I've said, virtio 1 will have exactly the same issue unless we start requiring firmware to advertise dma-coherent/_CCA for virtio-mmio devices correctly. Will

...set/unset correctly when VIRTIO_F_IOMMU_PLATFORM >>> is advertised by the device (which is what I suggested in my reply). >> >> I'm not ignoring that, but I need to understand that part a bit better. >> I'll reply to that patch in a day or two after looking at how _CCA is >> supposed to work. > > Thanks. I do think that whatever solution we come up with for virtio 1 > should influence what we do for legacy. > >>> We can't detect the fastmodel, >> >> Surely, it puts a hardware id somewhere? I think you mean >> fas...

...set correctly when VIRTIO_F_IOMMU_PLATFORM > > > is advertised by the device (which is what I suggested in my reply). > > > > I'm not ignoring that, but I need to understand that part a bit better. > > I'll reply to that patch in a day or two after looking at how _CCA is > > supposed to work. > > > > > We can't detect the fastmodel, > > > > Surely, it puts a hardware id somewhere? I think you mean > > fastmodel isn't always affected, right? > > > > > but we could implicitly treat virtio-mmio > &...

...F_IOMMU_PLATFORM >>>>> is advertised by the device (which is what I suggested in my reply). >>>> >>>> I'm not ignoring that, but I need to understand that part a bit better. >>>> I'll reply to that patch in a day or two after looking at how _CCA is >>>> supposed to work. >>> >>> Thanks. I do think that whatever solution we come up with for virtio 1 >>> should influence what we do for legacy. >>> >>>>> We can't detect the fastmodel, >>>> >>>> Surely,...

...ot;dma-coherent" property is set/unset correctly when VIRTIO_F_IOMMU_PLATFORM > is advertised by the device (which is what I suggested in my reply). I'm not ignoring that, but I need to understand that part a bit better. I'll reply to that patch in a day or two after looking at how _CCA is supposed to work. > We can't detect the fastmodel, Surely, it puts a hardware id somewhere? I think you mean fastmodel isn't always affected, right? > but we could implicitly treat virtio-mmio > devices as cache-coherent regardless of the "dma-coherent" flag. I alre...