On 24/02/2023 15:56, Alex Williamson wrote:
> On Fri, 24 Feb 2023 12:53:26 +
> Joao Martins wrote:
>
>> On 24/02/2023 11:25, Joao Martins wrote:
>>> On 23/02/2023 23:26, Jason Gunthorpe wrote:
On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
> On Thu, 23 Feb 2023
On Fri, 24 Feb 2023 12:53:26 +
Joao Martins wrote:
> On 24/02/2023 11:25, Joao Martins wrote:
> > On 23/02/2023 23:26, Jason Gunthorpe wrote:
> >> On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
> >>> On Thu, 23 Feb 2023 16:55:54 -0400
> >>> Jason Gunthorpe wrote:
>
On Fri, Feb 24, 2023 at 12:53:26PM +, Joao Martins wrote:
> > But reading the code this ::bypass_iommu (new to me) apparently tells that
> > vIOMMU is bypassed or not for the PCI devices all the way to avoiding
> > enumerating in the IVRS/DMAR ACPI tables. And I see VFIO double-checks
> >
On 24/02/2023 11:25, Joao Martins wrote:
> On 23/02/2023 23:26, Jason Gunthorpe wrote:
>> On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
>>> On Thu, 23 Feb 2023 16:55:54 -0400
>>> Jason Gunthorpe wrote:
On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
On 23/02/2023 23:26, Jason Gunthorpe wrote:
> On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
>> On Thu, 23 Feb 2023 16:55:54 -0400
>> Jason Gunthorpe wrote:
>>> On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
>>> Or even better figure out how to get interrupt
On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
> On Thu, 23 Feb 2023 16:55:54 -0400
> Jason Gunthorpe wrote:
>
> > On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
> > > > #2 is the presumption that the guest is using an identity map.
> > >
> > > This is a
On Thu, 23 Feb 2023 16:55:54 -0400
Jason Gunthorpe wrote:
> On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
> > > #2 is the presumption that the guest is using an identity map.
> >
> > This is a dangerous assumption.
> >
> > > > I'd think the only viable fallback if the
On 23/02/2023 20:55, Jason Gunthorpe wrote:
> On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
>>> #2 is the presumption that the guest is using an identity map.
>> Isn't it reasonable to require that a device support dirty tracking for
>> the entire extent if its DMA address width
On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
> > #2 is the presumption that the guest is using an identity map.
>
> This is a dangerous assumption.
>
> > > I'd think the only viable fallback if the vIOMMU doesn't report its max
> > > IOVA is the full 64-bit address space,
On Wed, 22 Feb 2023 22:08:33 -0400
Jason Gunthorpe wrote:
> On Wed, Feb 22, 2023 at 04:34:39PM -0700, Alex Williamson wrote:
> > > +/*
> > > + * With vIOMMU we try to track the entire IOVA space. As the IOVA
> > > space can
> > > + * be rather big, devices might not be able to track
On Wed, Feb 22, 2023 at 04:34:39PM -0700, Alex Williamson wrote:
> > +/*
> > + * With vIOMMU we try to track the entire IOVA space. As the IOVA
> > space can
> > + * be rather big, devices might not be able to track it due to HW
> > + * limitations. In that case:
> > + * (1)
On Wed, 22 Feb 2023 19:49:12 +0200
Avihai Horon wrote:
> Currently, device dirty page tracking with vIOMMU is not supported - RAM
> pages are perpetually marked dirty in this case.
>
> When vIOMMU is used, IOVA ranges are DMA mapped/unmapped on the fly as
> the vIOMMU maps/unmaps them. These
Currently, device dirty page tracking with vIOMMU is not supported - RAM
pages are perpetually marked dirty in this case.
When vIOMMU is used, IOVA ranges are DMA mapped/unmapped on the fly as
the vIOMMU maps/unmaps them. These IOVA ranges can potentially be mapped
anywhere in the vIOMMU IOVA
13 matches
Mail list logo
