search for: tlbi

...el. Even when the user does enable a vIOMMU for this case >>> (allowing to over-commit guest memory, which needs to be pinned >>> otherwise), >> >> BTW that's in theory in practice it doesn't really work. >> >>> we generally play tricks like lazy TLBI (non-strict mode) to >>> make it faster. >> >> Simple lazy TLB for guest/userspace drivers would be a big no no. >> You need something smarter. >> >>> Here device and drivers are trusted, therefore the >>> vulnerability window of lazy mode isn'...

...ce and drivers are trusted by the > guest kernel. Even when the user does enable a vIOMMU for this case > (allowing to over-commit guest memory, which needs to be pinned > otherwise), BTW that's in theory in practice it doesn't really work. > we generally play tricks like lazy TLBI (non-strict mode) to > make it faster. Simple lazy TLB for guest/userspace drivers would be a big no no. You need something smarter. > Here device and drivers are trusted, therefore the > vulnerability window of lazy mode isn't a concern. > > If the reason to enable the vIOMMU...

On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote: > On 23/11/2018 21:56, Michael S. Tsirkin wrote: > >> +config VIRTIO_IOMMU > >> + bool "Virtio IOMMU driver" > >> + depends on VIRTIO=y > >> + select IOMMU_API > >> + select INTERVAL_TREE > >> + select ARM_DMA_USE_IOMMU if ARM > >> + help > >>

...ire dma_map/unmap() to be fast, but there generally is no need for a vIOMMU, since device and drivers are trusted by the guest kernel. Even when the user does enable a vIOMMU for this case (allowing to over-commit guest memory, which needs to be pinned otherwise), we generally play tricks like lazy TLBI (non-strict mode) to make it faster. Here device and drivers are trusted, therefore the vulnerability window of lazy mode isn't a concern. If the reason to enable the vIOMMU is over-comitting guest memory however, you can't use nested translation because it requires pinning the second-leve...

...he >> guest kernel. Even when the user does enable a vIOMMU for this case >> (allowing to over-commit guest memory, which needs to be pinned >> otherwise), > > BTW that's in theory in practice it doesn't really work. > >> we generally play tricks like lazy TLBI (non-strict mode) to >> make it faster. > > Simple lazy TLB for guest/userspace drivers would be a big no no. > You need something smarter. > >> Here device and drivers are trusted, therefore the >> vulnerability window of lazy mode isn't a concern. >> >...

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.