On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote:
> >> Another way of looking at this issue which also explains our reluctance
> >> is that the only difference between a secure guest and a regular guest
> >> (at least regarding virtio) is that the former uses swiotlb while the
On 01/03/2019 20:20, Douglas Anderson wrote:
> If you're bisecting why your peripherals stopped working, it's
> probably this CL. Specifically if you see this in your dmesg:
> Unexpected global fault, this could be serious
> ...then it's almost certainly this CL.
>
> Running your
On 18.03.19 15:19:23, Robin Murphy wrote:
> On 15/03/2019 15:56, Robert Richter wrote:
> > We track the smallest size that failed for a 32 bit allocation. The
> > Size decreases only and if we actually walked the tree and noticed an
> > allocation failure. Current code is broken and wrongly
On 20/03/2019 15:48, Marc Gonzalez wrote:
On 01/03/2019 20:20, Douglas Anderson wrote:
If you're bisecting why your peripherals stopped working, it's
probably this CL. Specifically if you see this in your dmesg:
Unexpected global fault, this could be serious
...then it's almost certainly
The ARM architecture has a "Top Byte Ignore" (TBI) option that makes the
MMU mask out bits [63:56] of an address, allowing a userspace application
to store data in its pointers. This option is incompatible with PCI ATS.
If TBI is enabled in the SMMU and userspace triggers DMA transactions on
Root complex node in IORT has a bit telling whether it supports ATS or
not. Store this bit in the IOMMU fwspec when setting up a device, so it
can be accessed later by an IOMMU driver.
Use the negative version (NO_ATS) at the moment because it's not clear
if/how the bit needs to be integrated in
When removing a mapping from a domain, we need to send an invalidation to
all devices that might have stored it in their Address Translation Cache
(ATC). In addition when updating the context descriptor of a live domain,
we'll need to send invalidations for all devices attached to it.
Maintain a
On 20/03/2019 16:37, Jacob Pan wrote:
[...]
>> +struct iommu_inv_addr_info {
>> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0)
>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1)
>> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2)
>> +__u32 flags;
>> +__u32 archid;
>> +__u64 pasid;
>> +
Hello Michael,
Sorry for the delay in responding. We had some internal discussions on
this.
Michael S. Tsirkin writes:
> On Mon, Feb 04, 2019 at 04:14:20PM -0200, Thiago Jung Bauermann wrote:
>>
>> Hello Michael,
>>
>> Michael S. Tsirkin writes:
>>
>> > On Tue, Jan 29, 2019 at 03:42:44PM
This is the device driver API for SVA (Shared Virtual Addressing).
Changes since v1 [1]:
* Following comments, return a handle rather than a PASID. I agree that
it makes things easier for device drivers as well, because they don't
need to worry about the unbind()/mm_exit() race as much.
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address
When AVIC is enabled and the VM has discrete device assignment,
the interrupt remapping table (IRT) is used to keep track of which
destination APIC ID the IOMMU will inject the device interrput to.
This means every time a vcpu is blocked or context-switched (i.e.
vcpu_blocking/unblocking() and
Hi Neo,
On 3/9/19 2:03 AM, Neo Jia wrote:
On Thu, Mar 07, 2019 at 04:56:23PM -0700, Alex Williamson wrote:
On Thu, 7 Mar 2019 00:44:54 -0800
Neo Jia wrote:
On Fri, Feb 22, 2019 at 10:19:27AM +0800, Lu Baolu wrote:
This adds the support to determine the isolation type
of a mediated device
13 matches
Mail list logo
