search for: access_platform

...Go through the DMA API. >> > >> > Signed-off-by: Thiago Jung Bauermann <bauerman at linux.ibm.com> > > Well I think this will come back to bite us (witness xen which is now > reworking precisely this path - but at least they aren't to blame, xen > came before ACCESS_PLATFORM). > > I also still think the right thing would have been to set > ACCESS_PLATFORM for all systems where device can't access all memory. I understand. The problem with that approach for us is that because we don't know which guests will become secure guests and which will remain re...

...Go through the DMA API. >> > >> > Signed-off-by: Thiago Jung Bauermann <bauerman at linux.ibm.com> > > Well I think this will come back to bite us (witness xen which is now > reworking precisely this path - but at least they aren't to blame, xen > came before ACCESS_PLATFORM). > > I also still think the right thing would have been to set > ACCESS_PLATFORM for all systems where device can't access all memory. I understand. The problem with that approach for us is that because we don't know which guests will become secure guests and which will remain re...

...rites: > On Mon, Feb 04, 2019 at 04:14:20PM -0200, Thiago Jung Bauermann wrote: >> >> Hello Michael, >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: >> So while ACCESS_PLATFORM solves our problems for secure guests, we can't >> turn it on by default because we can't affect legacy systems. Doing so >> would penalize existing systems that can access all memory. They would >> all have to unnecessarily go through address translations, and take a >...

...rites: > On Mon, Feb 04, 2019 at 04:14:20PM -0200, Thiago Jung Bauermann wrote: >> >> Hello Michael, >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: >> So while ACCESS_PLATFORM solves our problems for secure guests, we can't >> turn it on by default because we can't affect legacy systems. Doing so >> would penalize existing systems that can access all memory. They would >> all have to unnecessarily go through address translations, and take a >...

...gt;> > > >> > Signed-off-by: Thiago Jung Bauermann <bauerman at linux.ibm.com> > > > > Well I think this will come back to bite us (witness xen which is now > > reworking precisely this path - but at least they aren't to blame, xen > > came before ACCESS_PLATFORM). > > > > I also still think the right thing would have been to set > > ACCESS_PLATFORM for all systems where device can't access all memory. > > I understand. The problem with that approach for us is that because we > don't know which guests will become secure g...

...is that the former uses swiotlb while the >> >> latter doens't. >> > >> > But swiotlb is just one implementation. It's a guest internal thing. The >> > issue is that memory isn't host accessible. >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> only ever try to access memory addresses that are supplied to it by the >> guest, so all of the secure guest memory that the host cares about is >> accessible: >> >> If this feature bit is set to 0, then the device has same access to &g...

...is that the former uses swiotlb while the >> >> latter doens't. >> > >> > But swiotlb is just one implementation. It's a guest internal thing. The >> > issue is that memory isn't host accessible. >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> only ever try to access memory addresses that are supplied to it by the >> guest, so all of the secure guest memory that the host cares about is >> accessible: >> >> If this feature bit is set to 0, then the device has same access to &g...

...least regarding virtio) is that the former uses swiotlb while the > >> latter doens't. > > > > But swiotlb is just one implementation. It's a guest internal thing. The > > issue is that memory isn't host accessible. > > >From what I understand of the ACCESS_PLATFORM definition, the host will > only ever try to access memory addresses that are supplied to it by the > guest, so all of the secure guest memory that the host cares about is > accessible: > > If this feature bit is set to 0, then the device has same access to > memory addre...

...M -0300, Thiago Jung Bauermann wrote: >> >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> >> >> only ever try to access memory addresses that are supplied to it by the >> >> >> guest, so all of the secure guest memory that the host cares about is >> >> >> accessible: >> >> >> >> &g...

...M -0300, Thiago Jung Bauermann wrote: >> >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> >> >> only ever try to access memory addresses that are supplied to it by the >> >> >> guest, so all of the secure guest memory that the host cares about is >> >> >> accessible: >> >> >> >> &g...

...lb while the > >> >> latter doens't. > >> > > >> > But swiotlb is just one implementation. It's a guest internal thing. The > >> > issue is that memory isn't host accessible. > >> > >> >From what I understand of the ACCESS_PLATFORM definition, the host will > >> only ever try to access memory addresses that are supplied to it by the > >> guest, so all of the secure guest memory that the host cares about is > >> accessible: > >> > >> If this feature bit is set to 0, then the dev...

...ites: > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> >> only ever try to access memory addresses that are supplied to it by the >> >> guest, so all of the secure guest memory that the host cares about is >> >> accessible: >> >> >> >> If this feature bit is se...

...ites: > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> >> only ever try to access memory addresses that are supplied to it by the >> >> guest, so all of the secure guest memory that the host cares about is >> >> accessible: >> >> >> >> If this feature bit is se...

...rmann wrote: > >> >> > >> >> Michael S. Tsirkin <mst at redhat.com> writes: > >> >> > >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: > >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will > >> >> >> only ever try to access memory addresses that are supplied to it by the > >> >> >> guest, so all of the secure guest memory that the host cares about is > >> >> >> accessible: > >> >>...

...; >> >> >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> >> >> >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> >> >> >> only ever try to access memory addresses that are supplied to it by the >> >> >> >> guest, so all of the secure guest memory that the host cares about is >> >> >> >> accessible: >> &g...

...1, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > >> > >> Michael S. Tsirkin <mst at redhat.com> writes: > >> > >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: > >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will > >> >> only ever try to access memory addresses that are supplied to it by the > >> >> guest, so all of the secure guest memory that the host cares about is > >> >> accessible: > >> >> > >> >>...

...0, Thiago Jung Bauermann wrote: >> >> >> I rephrased it in terms of address translation. What do you think of >> >> >> this version? The flag name is slightly different too: >> >> >> >> >> >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> >> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> >> >> with the exception that address translation is guaranteed to be >> >> >> unnecessary when accessing memory...

...0, Thiago Jung Bauermann wrote: >> >> >> I rephrased it in terms of address translation. What do you think of >> >> >> this version? The flag name is slightly different too: >> >> >> >> >> >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> >> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> >> >> with the exception that address translation is guaranteed to be >> >> >> unnecessary when accessing memory...

...sirkin <mst at redhat.com> writes: > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > 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 by the platform to identical >> > addresses. >> > >> > In fact this option then becomes more, not less restrictive >> > than VIRTI...

...sirkin <mst at redhat.com> writes: > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > 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 by the platform to identical >> > addresses. >> > >> > In fact this option then becomes more, not less restrictive >> > than VIRTI...