search for: slof

Hi, We are trying to set up XEN testbed on Thamesblue Supercomputer which has IBM JS20 Blades. I compiled the SLOF firmware from the source on one of the blade. The compilation went smooth and generated the following binaries *boot_rom.bin boot_rom_bimini.bin* When we try to flash boot_rom.bin firmware binary then we get the following error: * update_flash: RTAS: validate() Invalid candidate image for this p...

Hi, We are trying to set up XEN testbed on Thamesblue Supercomputer which has IBM JS20 Blades. I compiled the SLOF firmware from the source on one of the blade. The compilation went smooth and generated the following binaries *boot_rom.bin boot_rom_bimini.bin* When we try to flash boot_rom.bin firmware binary then we get the following error: * update_flash: RTAS: validate() Invalid candidate image for this p...

...- >> > possibly by causing a guest crash >> > or some other kind of platform-specific error >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is >> SLOF as I mentioned above, another is that we would be requiring all >> guests running on the machine (secure guests or not, since we would use >> the same configuration for all guests) to support it. But >> ACCESS_PLATFORM is relatively recent so it's a bit early for that. For &gt...

...- >> > possibly by causing a guest crash >> > or some other kind of platform-specific error >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is >> SLOF as I mentioned above, another is that we would be requiring all >> guests running on the machine (secure guests or not, since we would use >> the same configuration for all guests) to support it. But >> ACCESS_PLATFORM is relatively recent so it's a bit early for that. For &gt...

...turn means DMA API can be > fast - it does not need to do anything. What you are looking for is a > way to tell host it's an identity mapping - just as an optimization. > > Is that right? Almost. Theoretically it is just an optimization. But in practice the pseries boot firmware (SLOF) doesn't support IOMMU_PLATFORM so it's not possible to boot a guest from a device with that flag set. > So this is what I would call this option: > > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS > > and the explanation should state that all device > addresses are translated...

...turn means DMA API can be > fast - it does not need to do anything. What you are looking for is a > way to tell host it's an identity mapping - just as an optimization. > > Is that right? Almost. Theoretically it is just an optimization. But in practice the pseries boot firmware (SLOF) doesn't support IOMMU_PLATFORM so it's not possible to boot a guest from a device with that flag set. > So this is what I would call this option: > > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS > > and the explanation should state that all device > addresses are translated...

...est crash >> >> > or some other kind of platform-specific error >> >> >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring >> >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is >> >> SLOF as I mentioned above, another is that we would be requiring all >> >> guests running on the machine (secure guests or not, since we would use >> >> the same configuration for all guests) to support it. But >> >> ACCESS_PLATFORM is relatively recent so it's a...

...est crash >> >> > or some other kind of platform-specific error >> >> >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring >> >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is >> >> SLOF as I mentioned above, another is that we would be requiring all >> >> guests running on the machine (secure guests or not, since we would use >> >> the same configuration for all guests) to support it. But >> >> ACCESS_PLATFORM is relatively recent so it's a...

...; fast - it does not need to do anything. What you are looking for is a > > way to tell host it's an identity mapping - just as an optimization. > > > > Is that right? > > Almost. Theoretically it is just an optimization. But in practice the > pseries boot firmware (SLOF) doesn't support IOMMU_PLATFORM so it's not > possible to boot a guest from a device with that flag set. > > > So this is what I would call this option: > > > > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS > > > > and the explanation should state that all d...

...Another is that given the basic functionality is in there, optimizations > can possibly wait until per-device quirks in DMA API are supported. The point is that requiring specific qemu command line arguments isn't going to fly. We have additional problems due to the fact that our firmware (SLOF) inside qemu doesn't currently deal with iommu's etc... though those can be fixed. Overall, however, this seems to be the most convoluted way of achieving things, require user interventions where none should be needed etc... Again, what's wrong with a 2 lines hook instead that solves...

...Another is that given the basic functionality is in there, optimizations > can possibly wait until per-device quirks in DMA API are supported. The point is that requiring specific qemu command line arguments isn't going to fly. We have additional problems due to the fact that our firmware (SLOF) inside qemu doesn't currently deal with iommu's etc... though those can be fixed. Overall, however, this seems to be the most convoluted way of achieving things, require user interventions where none should be needed etc... Again, what's wrong with a 2 lines hook instead that solves...

...ibly by causing a guest crash > >> > or some other kind of platform-specific error > >> > >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring > >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is > >> SLOF as I mentioned above, another is that we would be requiring all > >> guests running on the machine (secure guests or not, since we would use > >> the same configuration for all guests) to support it. But > >> ACCESS_PLATFORM is relatively recent so it's a bit early fo...

...gt;> > or some other kind of platform-specific error > >> >> > >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring > >> >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is > >> >> SLOF as I mentioned above, another is that we would be requiring all > >> >> guests running on the machine (secure guests or not, since we would use > >> >> the same configuration for all guests) to support it. But > >> >> ACCESS_PLATFORM is relatively recent...

Michael S. Tsirkin <mst at redhat.com> writes: > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> I rephrased it in terms of address translation. What do you think of >>

Michael S. Tsirkin <mst at redhat.com> writes: > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> I rephrased it in terms of address translation. What do you think of >>

...e basic functionality is in there, optimizations > > can possibly wait until per-device quirks in DMA API are supported. > > The point is that requiring specific qemu command line arguments isn't > going to fly. We have additional problems due to the fact that our > firmware (SLOF) inside qemu doesn't currently deal with iommu's etc... > though those can be fixed. > > Overall, however, this seems to be the most convoluted way of achieving > things, require user interventions where none should be needed etc... > > Again, what's wrong with a 2 l...

...hat has an impact up the food chain (libvirt, management tools etc...) and users probably won't understand what it's about. In fact the *end user* might not even need to know a VM is secure, though applications inside might. There's the additional annoyance that currently our guest FW (SLOF) cannot deal with virtio in IOMMU mode, but that's fixable. >From there, refer to the email chain between Michael and I where we are discussing options to "switch" virtio at runtime on the qemu side. Any comment or suggestion ? Cheers, Ben.

...hat has an impact up the food chain (libvirt, management tools etc...) and users probably won't understand what it's about. In fact the *end user* might not even need to know a VM is secure, though applications inside might. There's the additional annoyance that currently our guest FW (SLOF) cannot deal with virtio in IOMMU mode, but that's fixable. >From there, refer to the email chain between Michael and I where we are discussing options to "switch" virtio at runtime on the qemu side. Any comment or suggestion ? Cheers, Ben.

On Fri, 2018-08-03 at 09:02 -0700, Christoph Hellwig wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-provided > > > > swiotlb callbacks when needed, that is when not using IOMMU *and* > > > >

On Fri, 2018-08-03 at 09:02 -0700, Christoph Hellwig wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-provided > > > > swiotlb callbacks when needed, that is when not using IOMMU *and* > > > >