search for: resv_mem

...basic > form of fault reporting mechanism to indicate such errors to guest. I am considering recoverable faults as the end goal, but reporting unrecoverable faults should use the same queue, with slightly different fields and no need for the driver to reply to the device. > 2.6.8.2 Property RESV_MEM > > I'm not immediately clear when VIRTIO_IOMMU_PROBE_RESV_MEM_T_ABORT > should be explicitly reported. Is there any real example on bare metal IOMMU? > usually reserved memory is reported to CPU through other method (e.g. e820 > on x86 platform). Of course MSI is a special case...

...basic > form of fault reporting mechanism to indicate such errors to guest. I am considering recoverable faults as the end goal, but reporting unrecoverable faults should use the same queue, with slightly different fields and no need for the driver to reply to the device. > 2.6.8.2 Property RESV_MEM > > I'm not immediately clear when VIRTIO_IOMMU_PROBE_RESV_MEM_T_ABORT > should be explicitly reported. Is there any real example on bare metal IOMMU? > usually reserved memory is reported to CPU through other method (e.g. e820 > on x86 platform). Of course MSI is a special case...

...t; fields and no need for the driver to reply to the device. what about adding a placeholder for now? Though same mechanism can be reused, it's an essential part to make virtio-iommu architecture complete even before talking support for recoverable faults. :-) > > > 2.6.8.2 Property RESV_MEM > > > > I'm not immediately clear when > VIRTIO_IOMMU_PROBE_RESV_MEM_T_ABORT > > should be explicitly reported. Is there any real example on bare metal > IOMMU? > > usually reserved memory is reported to CPU through other method (e.g. > e820 > > on x86 pla...

...H we send a MAP for the whole input range. If the > change isn't bigger than this, I'll add it to v5. Not as straightforward as I hoped, when the device doesn't support VIRTIO_IOMMU_F_BYPASS: * We can't simply create an ID map for the whole input range, we need to carve out the resv_mem regions. * For a VFIO device, the host has no way of forwarding the identity mapping. For example the guest will attempt to map [0; 0xffffffffffff] -> [0; 0xffffffffffff], but VFIO only allows to map RAM and cannot take such request. One solution is to only create ID mapping for RAM, and regist...

...ions are without looking at the implementation, maybe using names from the device point of view is more clear. I don't mind simplifying though, as I don't see a reason for the driver to know about BYPASS regions other than HW MSIs. How about I remove ABORT and BYPASS, make the only subtype RESV_MEM_T_MSI (1)? We'd use subtype 0 as "don't care, just don't map this". Can call it RESV_MEM_T_RESERVED. Flags won't be used for these subtypes. Another subtype will be RESV_MEM_T_IDENTITY (see my reply to Kevin). IDENTITY regions must be identity-mapped by the guest and, as...

...ions are without looking at the implementation, maybe using names from the device point of view is more clear. I don't mind simplifying though, as I don't see a reason for the driver to know about BYPASS regions other than HW MSIs. How about I remove ABORT and BYPASS, make the only subtype RESV_MEM_T_MSI (1)? We'd use subtype 0 as "don't care, just don't map this". Can call it RESV_MEM_T_RESERVED. Flags won't be used for these subtypes. Another subtype will be RESV_MEM_T_IDENTITY (see my reply to Kevin). IDENTITY regions must be identity-mapped by the guest and, as...

...res cleanly in the next > versions. In the same vein, the few remaining "device" occurrences were > replaced by "endpoint", to avoid any confusion with "the device" > referring to the virtio device across the document. > * Add implementation notes for RESV_MEM properties. > * Update ACPI table definition. > * Fix typos and clarify a few things. > > I will publish the Linux driver for v0.5 shortly. Then for next versions > I'll focus on optimizations and adding support for hardware acceleration. > > Existing implementations are...

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

Hi Jean-Philippe, On 17/11/17 19:52, Jean-Philippe Brucker wrote: > When the device offers the probe feature, send a probe request for each > device managed by the IOMMU. Extract RESV_MEM information. When we > encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. > This will tell other subsystems that there is no need to map the MSI > doorbell in the virtio-iommu, because MSIs bypass it. > > Signed-off-by: Jean-Philippe Brucker <jean-philippe.bru...

...; versions. In the same vein, the few remaining "device" occurrences were > >> replaced by "endpoint", to avoid any confusion with "the device" > >> referring to the virtio device across the document. > >> * Add implementation notes for RESV_MEM properties. > >> * Update ACPI table definition. > >> * Fix typos and clarify a few things. > >> > >> I will publish the Linux driver for v0.5 shortly. Then for next versions > >> I'll focus on optimizations and adding support for hardware accelerati...

...; versions. In the same vein, the few remaining "device" occurrences were > >> replaced by "endpoint", to avoid any confusion with "the device" > >> referring to the virtio device across the document. > >> * Add implementation notes for RESV_MEM properties. > >> * Update ACPI table definition. > >> * Fix typos and clarify a few things. > >> > >> I will publish the Linux driver for v0.5 shortly. Then for next versions > >> I'll focus on optimizations and adding support for hardware accelerati...

Please find version 0.6 of the virtio-iommu specification at the following locations. Document: http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.pdf http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.html Sources: git://linux-arm.org/virtio-iommu.git viommu/v0.6 I didn't receive any comment for v0.5 [1], so this update is fairly light: * Changed range definition in map and

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, September 6, 2017 7:49 PM > > > > 2.6.8.2.1 > > Multiple overlapping RESV_MEM properties are merged together. Device > > requirement? if same types I assume? > > Combination rules apply to device and driver. When the driver puts > multiple endpoints in the same domain, combination rules apply. They will > become important once the guest attempts to do thin...

...n the same vein, the few remaining "device" occurrences were > > >> replaced by "endpoint", to avoid any confusion with "the device" > > >> referring to the virtio device across the document. > > >> * Add implementation notes for RESV_MEM properties. > > >> * Update ACPI table definition. > > >> * Fix typos and clarify a few things. > > >> > > >> I will publish the Linux driver for v0.5 shortly. Then for next versions > > >> I'll focus on optimizations and adding suppor...

...SIDs and other features cleanly in the next versions. In the same vein, the few remaining "device" occurrences were replaced by "endpoint", to avoid any confusion with "the device" referring to the virtio device across the document. * Add implementation notes for RESV_MEM properties. * Update ACPI table definition. * Fix typos and clarify a few things. I will publish the Linux driver for v0.5 shortly. Then for next versions I'll focus on optimizations and adding support for hardware acceleration. Existing implementations are simple and can certainly be optimiz...

...SIDs and other features cleanly in the next versions. In the same vein, the few remaining "device" occurrences were replaced by "endpoint", to avoid any confusion with "the device" referring to the virtio device across the document. * Add implementation notes for RESV_MEM properties. * Update ACPI table definition. * Fix typos and clarify a few things. I will publish the Linux driver for v0.5 shortly. Then for next versions I'll focus on optimizations and adding support for hardware acceleration. Existing implementations are simple and can certainly be optimiz...

This is version 0.7 of the virtio-iommu specification. The diff from 0.6, included below, is fairly small and consists of the following changes: * Address comments from 0.6, rework bits of the implementation notes. * Change resv_mem parameters to be consistent with the rest of the spec. * Add the MMIO flag to MAP requests. At the moment it is used by mapped MSIs mostly for completeness, but will be important for IDENTITY resv_mem regions that next versions introduce. Please find more information about this on the v0.6...

Hi Jean, On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote: > When the device offers the probe feature, send a probe request for each > device managed by the IOMMU. Extract RESV_MEM information. When we > encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. > This will tell other subsystems that there is no need to map the MSI > doorbell in the virtio-iommu, because MSIs bypass it. > > Signed-off-by: Jean-Philippe Brucker <jean-philippe.bru...

...ontinuing operation with modified value? --2.6.4 DETACH request-- " Detach an endpoint from its domain. When this request completes, the endpoint cannot access any mapping from that domain anymore " Does it make sense to mention BYPASS situation upon this request? --2.6.8.2 Property RESV_MEM -- "VIRTIO_IOMMU_RESV_MEM_T_RESERVED (0) Accesses to virtual addresses in this region are not translated by the device. They may either be aborted by the device (or the underlying IOMMU), bypass it, or never even reach it" in 3.3 hardware device assignment you described an example t...