search for: plaform

...eded, that is when not using IOMMU *and* > > running on a secure VM in our case. > > And total NAK the customer platform-provided part of this. We need > a flag passed in from the hypervisor that the device needs all bus > specific dma api treatment, and then just use the normal plaform > dma mapping setup. Christoph, as I have explained already, we do NOT have a way to provide such a flag as neither the hypervisor nor qemu knows anything about this when the VM is created. > To get swiotlb you'll need to then use the DT/ACPI > dma-range property to limit the addre...

...eded, that is when not using IOMMU *and* > > running on a secure VM in our case. > > And total NAK the customer platform-provided part of this. We need > a flag passed in from the hypervisor that the device needs all bus > specific dma api treatment, and then just use the normal plaform > dma mapping setup. Christoph, as I have explained already, we do NOT have a way to provide such a flag as neither the hypervisor nor qemu knows anything about this when the VM is created. > To get swiotlb you'll need to then use the DT/ACPI > dma-range property to limit the addre...

On Mon, 2018-08-06 at 23:21 -0700, Christoph Hellwig wrote: > On Tue, Aug 07, 2018 at 05:52:12AM +1000, Benjamin Herrenschmidt wrote: > > > It is your job to write a coherent interface specification that does > > > not depend on the used components. The hypervisor might be PAPR, > > > Linux + qemu, VMware, Hyperv or something so secret that you'd have > >

On Mon, 2018-08-06 at 23:21 -0700, Christoph Hellwig wrote: > On Tue, Aug 07, 2018 at 05:52:12AM +1000, Benjamin Herrenschmidt wrote: > > > It is your job to write a coherent interface specification that does > > > not depend on the used components. The hypervisor might be PAPR, > > > Linux + qemu, VMware, Hyperv or something so secret that you'd have > >

On Thu, 2018-08-02 at 23:52 +0300, Michael S. Tsirkin wrote: > > Yes, this is the purpose of Anshuman original patch (I haven't looked > > at the details of the patch in a while but that's what I told him to > > implement ;-) : > > > > - Make virtio always use DMA ops to simplify the code path (with a set > > of "transparent" ops for legacy)

On Thu, 2018-08-02 at 23:52 +0300, Michael S. Tsirkin wrote: > > Yes, this is the purpose of Anshuman original patch (I haven't looked > > at the details of the patch in a while but that's what I told him to > > implement ;-) : > > > > - Make virtio always use DMA ops to simplify the code path (with a set > > of "transparent" ops for legacy)

...> > running on a secure VM in our case. > > > > > > And total NAK the customer platform-provided part of this. We need > > > a flag passed in from the hypervisor that the device needs all bus > > > specific dma api treatment, and then just use the normal plaform > > > dma mapping setup. > > > > Christoph, as I have explained already, we do NOT have a way to provide > > such a flag as neither the hypervisor nor qemu knows anything about > > this when the VM is created. > > I think the fact you can't add flags fr...

...> > running on a secure VM in our case. > > > > > > And total NAK the customer platform-provided part of this. We need > > > a flag passed in from the hypervisor that the device needs all bus > > > specific dma api treatment, and then just use the normal plaform > > > dma mapping setup. > > > > Christoph, as I have explained already, we do NOT have a way to provide > > such a flag as neither the hypervisor nor qemu knows anything about > > this when the VM is created. > > I think the fact you can't add flags fr...

...swiotlb callbacks when needed, that is when not using IOMMU *and* > running on a secure VM in our case. And total NAK the customer platform-provided part of this. We need a flag passed in from the hypervisor that the device needs all bus specific dma api treatment, and then just use the normal plaform dma mapping setup. To get swiotlb you'll need to then use the DT/ACPI dma-range property to limit the addressable range, and a swiotlb capable plaform will use swiotlb automatically.

...ing IOMMU *and* > > > running on a secure VM in our case. > > > > And total NAK the customer platform-provided part of this. We need > > a flag passed in from the hypervisor that the device needs all bus > > specific dma api treatment, and then just use the normal plaform > > dma mapping setup. > > Christoph, as I have explained already, we do NOT have a way to provide > such a flag as neither the hypervisor nor qemu knows anything about > this when the VM is created. I think the fact you can't add flags from the hypervisor is a sign of a pr...

...M in the flags should do the work (even if that isn't strictly what the current definition of the flag actually means). On the qemu side you'll need to make sure you have a way to set VIRTIO_F_IOMMU_PLATFORM without emulating an iommu, but with code to take dma offsets into account if your plaform has any (various power plaforms seem to have them, not sure if it affects your config).

On 08/25/2016 10:44 AM, Gordon Messmer wrote: > On 08/25/2016 09:49 AM, Kay Schenk wrote: >> I do realize the sane thing to do is to have the builbots -- >> smoketest environments -- match the production environment > > > I think the sane thing to do would be to use buildbots that support LSB: > > http://www.ludism.org/~rwhe/LSB/tutorial/tut.html Great resource!

SuSE 7.2, Samba 2.2.6 User plaform WIN98se Was wondering if someone could point me to information regarding oplocks (I read the man on smb.conf regarding that and level2 oplocks)... I needed to set oplocks = no and level2 oplocks = no in order for them to be able to open pagemaker files from the samba server...otherwise it would...

...> > running on a secure VM in our case. > > > > > > And total NAK the customer platform-provided part of this. We need > > > a flag passed in from the hypervisor that the device needs all bus > > > specific dma api treatment, and then just use the normal plaform > > > dma mapping setup. > > > > Christoph, as I have explained already, we do NOT have a way to provide > > such a flag as neither the hypervisor nor qemu knows anything about > > this when the VM is created. > > I think the fact you can't add flags fr...

...eded, that is when not using IOMMU *and* > > running on a secure VM in our case. > > And total NAK the customer platform-provided part of this. We need > a flag passed in from the hypervisor that the device needs all bus > specific dma api treatment, and then just use the normal plaform > dma mapping setup. To get swiotlb you'll need to then use the DT/ACPI > dma-range property to limit the addressable range, and a swiotlb > capable plaform will use swiotlb automatically. It seems reasonable to teach a platform to override dma-range for a specific device e.g. in cas...

...eded, that is when not using IOMMU *and* > > running on a secure VM in our case. > > And total NAK the customer platform-provided part of this. We need > a flag passed in from the hypervisor that the device needs all bus > specific dma api treatment, and then just use the normal plaform > dma mapping setup. To get swiotlb you'll need to then use the DT/ACPI > dma-range property to limit the addressable range, and a swiotlb > capable plaform will use swiotlb automatically. It seems reasonable to teach a platform to override dma-range for a specific device e.g. in cas...

...n a secure VM in our case. > > > > > > > > And total NAK the customer platform-provided part of this. We need > > > > a flag passed in from the hypervisor that the device needs all bus > > > > specific dma api treatment, and then just use the normal plaform > > > > dma mapping setup. > > > > > > Christoph, as I have explained already, we do NOT have a way to provide > > > such a flag as neither the hypervisor nor qemu knows anything about > > > this when the VM is created. > > > > I think...

...; do the work (even if that isn't strictly what the current definition > of the flag actually means). On the qemu side you'll need to make > sure you have a way to set VIRTIO_F_IOMMU_PLATFORM without emulating > an iommu, but with code to take dma offsets into account if your > plaform has any (various power plaforms seem to have them, not sure > if it affects your config). Something like that yes. I prefer a slightly different way, see below, any but in both cases, it should alleviate your concerns since it means there would be no particular mucking around with DMA ops at al...

...; do the work (even if that isn't strictly what the current definition > of the flag actually means). On the qemu side you'll need to make > sure you have a way to set VIRTIO_F_IOMMU_PLATFORM without emulating > an iommu, but with code to take dma offsets into account if your > plaform has any (various power plaforms seem to have them, not sure > if it affects your config). Something like that yes. I prefer a slightly different way, see below, any but in both cases, it should alleviate your concerns since it means there would be no particular mucking around with DMA ops at al...

On Sun, 2018-08-05 at 00:29 -0700, Christoph Hellwig wrote: > On Sun, Aug 05, 2018 at 11:10:15AM +1000, Benjamin Herrenschmidt wrote: > > - One you have rejected, which is to have a way for "no-iommu" virtio > > (which still doesn't use an iommu on the qemu side and doesn't need > > to), to be forced to use some custom DMA ops on the VM side. > > >