mode. Should it be:
if (!cap_caching_mode(iommu->cap) || did)
?
Either way, it wants a comment.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send th
On Thu, 2011-06-23 at 17:31 +0200, Joerg Roedel wrote:
> David, I think especially VT-d can benefit from such a callback. I will
> implement support for it in the AMD IOMMU driver and post a patch-set
> soon.
>
> Any comments, thoughts?
Ick. We *already* do the flushes as appropriate while we're
On Thu, 2011-11-10 at 14:17 +0800, Kai Huang wrote:
> And another question: have we considered the IOTLB flush operation? I
> think we need to implement similar logic when flush the DVMA range.
> Intel VT-d's manual says software needs to specify the appropriate
> mask value to flush large pages, b
On Thu, 2011-11-10 at 18:09 +0100, Joerg Roedel wrote:
> The requirement for the DMA-API is, that the IOTLB must be consistent
> with existing mappings, and only with the parts that are really mapped.
> The unmapped parts are not important.
>
> This allows nice optimizations like your 'batched unm
On Fri, 2011-11-11 at 13:58 +0100, Joerg Roedel wrote:
> For AMD IOMMU there is a feature called not-present cache. It says that
> the IOMMU caches non-present entries as well and needs an IOTLB flush
> when something is mapped (meant for software implementations of the
> IOMMU).
> So it can't be r
On Fri, 2012-03-23 at 02:54 +, Hao, Xudong wrote:
> Any other comments for this patch? Or can you check-in it in your
> iommu tree?
Apologies for the delayed response. I've just forwarded this to Linus.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
On Thu, 2011-04-21 at 15:28 +0100, Alex Williamson wrote:
> I've been wondering the exact same thing. My last patch took weeks of
> prodding, finally went into the maintainer's tree without
> acknowledgment, and there's hardly been any activity there to suggest
> a pull request for 2.6.39 is going
= PAGE_SIZE << gfp_order;
+
dma_pte_clear_range(dmar_domain, iova >> VTD_PAGE_SHIFT,
(iova + size - 1) >> VTD_PAGE_SHIFT);
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Fri, 2011-06-03 at 20:31 +0100, David Woodhouse wrote:
>
> + size = PAGE_SIZE << gfp_order;
Just realised it needs an extra <<9 in there somewhere, if you actually
wanted to test it (Allen). I think I'd prefer to fix the KVM code
instead, though.
--
d
On Fri, 3 Jun 2011, Alex Williamson wrote:
> On Fri, 2011-06-03 at 20:31 +0100, David Woodhouse wrote:
> > Tell me it isn't so...
>
> Looks accurate to me, in fact, with hugetlbfs it seems like it's doing
> exactly what it should do. The non-hugetlbfs case isn'
On Tue, 2011-06-07 at 06:38 -0700, Chris Wright wrote:
> I think we still leak the list entry though. Bottom line is that we
> need to handle hotplug ADD_DEVICE and DEL_DEVICE notifications. We
> happen to pick up ADD_DEVICE by accident, but it's all pretty sloppy.
Yeah, keeping a list of possi
On Tue, 2011-06-07 at 08:10 -0700, Chris Wright wrote:
> * David Woodhouse (dw...@infradead.org) wrote:
> > On Tue, 2011-06-07 at 06:38 -0700, Chris Wright wrote:
> > > I think we still leak the list entry though. Bottom line is that we
> > > need to handle hotplu
On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
>
> > Certainly an option, but that is a long-term project.
>
> Out of curiousity, are there other benefits to using coreboot as a core
> firmware in QEMU?
>
> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
I li
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> Where is CorebootPkg available from?
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
> > And it helps to dispel the stupid misconception in some quarters that
> > Coreboot *competes* with UEFI and thus cannot possibly be supported
> > bec
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse
> wrote:
> > On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
> >> Where is CorebootPkg available from?
> >
> > https://github.com/pgeorgi/edk2/tree/co
On Wed, 2013-05-29 at 21:12 -0400, Kevin O'Connor wrote:
>
> I remain doubtful that QOM has all the info needed to generate the
> BIOS tables. Does QOM describe how the 5th pci device uses global
> interrupt 11 when using global interrupts, legacy interrupt 5 when not
> using global interrupts, a
On Fri, 2013-05-31 at 07:58 -0500, Anthony Liguori wrote:
> What about a small change to the SeaBIOS build system to allow ACPI
> table generation to be done via a "plugin".
SeaBIOS already accepts ACPI tables from Coreboot or UEFI, and queries
them to find things that it needs.
> This could be a
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>
>
>
> Fork OVMF, drop the fat module, and just add GPL code. It's an easily
> solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a single module. Which is actually included in *binar
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
> It's even more fundamental. OVMF as a whole (at least in it's usable
> form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So in a sense you're right.
But we're talking here about
On Thu, 2013-12-05 at 23:38 +0100, Laszlo Ersek wrote:
>
> Does gas support mode switches in one file? I found examples on the
> net (for nasm I think) where people were thunking to real mode and
> back to protected mode in a single assembly file, and they could use
> native mnemonics for each par
even
calling it only for domains which have ATS-capable devices attached.
How about using a flag similar to iommu_snooping, which is recalculated
only when you add or remove a device? And only calling
iommu_flush_dev_iotlb() if that's set?
--
David WoodhouseOpe
spin_unlock_irqrestore(&device_domain_lock, flags);
What if there's more than one device? You only enable ATS for the first
device that supports it, and ignore the others?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
at_ much of a performance issue?
See the way that ppc64 handles it -- on a machine with overcommitted
virtual cpus, it will call __spin_yield (arch/powerpc/lib/locks.c) on
contention, which may cause the virtual CPU to donate its hypervisor
timeslice to the vCPU which is actually holding t
urther muttering to you that it
might make sense to set up such a tree.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
th
uild after people apply the ATS on their tree.
In what way will it depend on SR-IOV?
> So Dave, can I get an ack from you and let Jesse pull the IOMMU change
> to his tree? Or let this ATS go to 2.6.31?
Want to show the latest version of the patches which depend on SR-IOV,
and I c
On Thu, 2009-05-14 at 10:32 +0800, Yu Zhao wrote:
> Make iommu_flush_iotlb_psi() and flush_unmaps() more readable.
This doesn't apply any more.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Cor
fp_order;
Um, that's not a page-size based interface. Page size isn't always 4KiB;
this code runs on IA64 too.
We have enough fun with CPU vs. DMA page size on IA64 already :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Thu, 2009-02-26 at 17:31 +0800, Han, Weidong wrote:
> When assign a device behind conventional PCI bridge or PCIe to
> PCI/PCI-x bridge to a domain, it must assign its bridge and may
> also need to assign secondary interface to the same domain.
>
> Dependent assignment is already there, but de
On Tue, 2010-06-15 at 16:10 +0200, Joerg Roedel wrote:
> On Mon, Jun 14, 2010 at 07:19:17PM -0400, David Woodhouse wrote:
> > Why not just jump straight to the 'DMA proxy' device, and use that
> > _only_?
>
> Not sure about Intel chipsets, but on AMD chipset a leg
On Thu, 2010-06-17 at 11:35 +0800, Weidong Han wrote:
> David Woodhouse wrote:
> > So why do we bother setting up a context in the IOMMU for the device
> > itself, when no DMA will ever appear to come from this device? And
> >
> if the device is behind PCI Express-
On Thu, 2010-06-17 at 18:10 +0800, Sheng Yang wrote:
>
> BTW: I think this need to be queued for 2.6.35-rc as well.
I sent Linus the pull request yesterday.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Wed, 2008-12-10 at 15:11 +0100, Joerg Roedel wrote:
> So now its open how this will be merged alltogether. We can merge it in
> three steps (first from Dave's tree, then Avi and at last my IOMMU
> updates which has to happen in that order).
> The other option is to merge this all with one pull-r
in one domain */
-#define DOMAIN_FLAG_P2P_MULTIPLE_DEVICES (1 < 0)
+#define DOMAIN_FLAG_P2P_MULTIPLE_DEVICES (1 << 0)
/* domain represents a virtual machine, more than one devices
* across iommus may be owned in one domain, e.g. kvm guest.
--
David Woodhouse
On Wed, 2008-12-10 at 19:42 +0100, Joerg Roedel wrote:
> Ok, I add it, thanks. Who is the author, Mike or you?
Might as well attribute it to Mike; he spotted it.
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordo
whole lot through my iommu tree. OK?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to maj
On Tue, 2008-07-01 at 21:32 +0200, Sam Ravnborg wrote:
> On Tue, Jul 01, 2008 at 07:27:16PM +0300, Adrian Bunk wrote:
> > This patch removes the dummy asm/kvm.h files on architectures not (yet)
> > supporting KVM and uses the same conditional headers installation as
> > already used for a.out.h .
On Mon, 2015-11-02 at 08:10 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2015-11-01 at 09:45 +0200, Shamir Rabinovitch wrote:
> > Not sure this use case is possible for Infiniband where application hold
> > the data buffers and there is no way to force application to re use the
> > buffer as sug
On Sun, 2015-11-08 at 12:37 +0200, Michael S. Tsirkin wrote:
> On Thu, Oct 29, 2015 at 05:18:56PM +0100, David Woodhouse wrote:
> > On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
> > >
> > > But you trust your hypervisor (you have no choice anyway),
&
On Wed, 2015-11-11 at 07:56 -0800, Andy Lutomirski wrote:
>
> Can you flesh out this trick?
>
> On x86 IIUC the IOMMU more-or-less defaults to passthrough. If the
> kernel wants, it can switch it to a non-passthrough mode. My patches
> cause the virtio driver to do exactly this, except that the
On Thu, 2015-11-12 at 13:09 +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 11, 2015 at 11:30:27PM +0100, David Woodhouse wrote:
> >
> > If the IOMMU is exposed, and enabled, and telling the guest kernel that
> > it *does* cover the virtio devices, then those virtio devices
gt; IOMMU off.
Was this with ATS on or off? With ATS, the cost of the page walk can be
amortised in some cases — you can look up the physical address *before*
you are ready to actually start the DMA to it, and don't take that
latency at the time you're actually moving the data.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
On Thu, 2015-11-19 at 13:59 -0800, Andy Lutomirski wrote:
>
> >
> > So thinking hard about it, I don't see any real drawbacks to making this
> > conditional on a new feature bit, that Xen can then set..
>
> Can you elaborate? If I run QEMU, hosting Xen, hosting Linux, and the
> virtio device is
On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote:
>
>
> I tried to generate a DMAR table that excludes some devices from
> IOMMU translation, however it does not help.
>
> The reason is, as far as I understand, that Linux kernel does
> not allow any device being outside an IOMMU scope i
On Fri, 2015-11-20 at 10:21 +0200, Michael S. Tsirkin wrote:
>
> David, there are two things a hypervisor needs to tell the guest.
> 1. The actual device is behind an IOMMU. This is what you
> are suggesting we use DMAR for.
> 2. Using IOMMU from kernel (as opposed to from userspace with VFIO)
> There's that, and there's an "I care about security, but
> do not want to burn up cycles on fake protections that
> do not work" case.
It would seem to make most sense for this use case simply *not* to expose
virtio devices to guests as being behind an IOMMU at all. Sure, there are
esoteric us
> There's that, and there's an "I care about security, but
> do not want to burn up cycles on fake protections that
> do not work" case.
It would seem to make most sense for this use case simply *not* to expose
virtio devices to guests as being behind an IOMMU at all. Sure, there are
esoteric us
ro and use that throughout the code instead of the
hard-coded 'false' for little-endian.
This restores the ABI to match 4.1 and earlier kernels, and makes my
test program work again.
Signed-off-by: David Woodhouse
---
Or perhaps we should just use (__force u16) and (__force __virtio16)
ro and use that throughout the code instead of the
hard-coded 'false' for little-endian.
This restores the ABI to match 4.1 and earlier kernels, and makes my
test program work again.
Signed-off-by: David Woodhouse
---
On Wed, 2015-09-23 at 11:09 -0700, David Miller wrote:
f I'm going to define my own accessors, I'd probably just make them
use (__force __virtio16). But TBH none of the options seemed
particularly pretty to me. I can live with what we have.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.
On Wed, 2015-10-28 at 11:15 +0900, Joerg Roedel wrote:
> On Tue, Oct 27, 2015 at 06:17:10PM -0700, Andy Lutomirski wrote:
> > From: Andy Lutomirski
> >
> > This fixes virtio-pci on platforms and busses that have IOMMUs.
> > This
> > will break the experimental QEMU Q35 IOMMU support until QEMU
On Wed, 2015-10-28 at 14:52 +0900, Christian Borntraeger wrote:
>0059b25a: e3201024 lg %r2,32(%r1)
> #0059b260: e310b0a4 lg %r1,160(%r11)
> >0059b266: 4810100c lh %r1,12(%r1)
Precisely what is that
On Sun, 2015-10-25 at 09:07 -0700, Shamir Rabinovitch wrote:
>
> +
> +DMA_ATTR_IOMMU_BYPASS
> +-
> +
> > +For systems with IOMMU it is assumed all DMA translations use the IOMMU.
Not entirely true. We have per-device dma_ops on a most architectures
already, and we were just ta
On Tue, 2015-10-27 at 23:38 -0700, Andy Lutomirski wrote:
>
> Changes from v2:
> - Fix really embarrassing bug. This version actually works.
So embarrassing you didn't want to tell us what it was? ...
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -292,7 +292,7 @@ sta
On Wed, 2015-10-28 at 16:40 +0900, Christian Borntraeger wrote:
> Am 28.10.2015 um 16:17 schrieb Michael S. Tsirkin:
> > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote:
> > > This switches virtio to use the DMA API unconditionally. I'm sure
> > > it breaks things, but it seems to
On Wed, 2015-10-28 at 13:10 +0200, Shamir Rabinovitch wrote:
> On Wed, Oct 28, 2015 at 03:30:01PM +0900, David Woodhouse wrote:
> > > > +For systems with IOMMU it is assumed all DMA translations use the
> > > > IOMMU.
> >
> > Not entirely true. We have per
On Wed, 2015-10-28 at 13:23 +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 28, 2015 at 05:36:53PM +0900, Benjamin Herrenschmidt
> wrote:
> > On Wed, 2015-10-28 at 16:40 +0900, Christian Borntraeger wrote:
> > > We have discussed that at kernel summit. I will try to implement
> > > a dummy dma_ops f
On Wed, 2015-10-28 at 13:35 +0200, Michael S. Tsirkin wrote:
> E.g. on intel x86, there's an option iommu=pt which does the 1:1
> thing for devices when used by kernel, but enables
> the iommu if used by userspace/VMs.
That's none of your business.
You call the DMA API when you do DMA. That's all
On Wed, 2015-10-28 at 07:07 -0700, David Miller wrote:
> In the sparc64 case, the 64-bit DMA address space is divided into
> IOMMU translated and non-IOMMU translated.
>
> You just set the high bits differently depending upon what you want.
Wait, does that mean a (rogue) device could *always* get
On Wed, 2015-10-28 at 16:05 +0200, Michael S. Tsirkin wrote:
>
> Short answer - platforms need a way to discover, and express different
> security requirements of different devices.
Sure. PLATFORMS need that. Do not let it go anywhere near your device
drivers. Including the virtio drivers.
> If
On Wed, 2015-10-28 at 16:22 +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 28, 2015 at 11:13:29PM +0900, David Woodhouse wrote:
> > On Wed, 2015-10-28 at 16:05 +0200, Michael S. Tsirkin wrote:
> > >
> > > Short answer - platforms need a way to discover, and express
>
On Thu, 2015-10-29 at 09:32 +0900, Benjamin Herrenschmidt wrote:
> On Power, I generally have 2 IOMMU windows for a device, one at the
> bottom is remapped, and is generally used for 32-bit devices and the
> one at the top us setup as a bypass
So in the normal case of decent 64-bit devices (and
On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
>
> Example: you have a mix of assigned devices and virtio devices. You
> don't trust your assigned device vendor not to corrupt your memory so
> you want to limit the damage your assigned device can do to your
> guest,
> so you use an I
On Thu, 2015-10-29 at 11:31 -0700, Andy Lutomirski wrote:
> On Oct 28, 2015 6:11 PM, "Benjamin Herrenschmidt"
> wrote:
> >
> > On Thu, 2015-10-29 at 09:42 +0900, David Woodhouse wrote:
> > > On Thu, 2015-10-29 at 09:32 +0900, Benjamin Herrenschmidt wrote:
(Sorry, missed part of this before).
On Thu, 2015-10-29 at 11:01 +0200, Michael S. Tsirkin wrote:
> Isn't this specified by the hypervisor? I don't think this is a good
> way to do this: guest security should be up to guest.
And it is. When the guest sees an IOMMU, it can choose to use it, or
cho
y for it to do so.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
> + bool (*capability)(enum irq_remap_cap);
> +
Does this need to be a function call? Or could we just have a set of
flags in the irq_remap_ops instead, with less overhead to check them?
--
David WoodhouseOpen Source Technology Centre
david.w
On Fri, 2014-12-12 at 23:14 +0800, Feng Wu wrote:
> Add helper function to detect VT-d Posted-Interrupts capability.
>
> Signed-off-by: Feng Wu
> Reviewed-by: Jiang Liu
Acked-by: David Woodhouse
--
David WoodhouseOpen Source Technology Centre
return 0;
> +
If a new IOMMU is hotplugged now which doesn't support posted
interrupts, what happens?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
is set in Posted-Interrupts Descriptor, and the migration
> happens during vCPU scheduling.
>
> However, we still update the cached irte here, which can be used
> when changing back to remapping mode.
>
> Signed-off-by: Feng Wu
> Reviewed-by: Jiang Liu
Acked-by: David Woodhouse
--
On Fri, 2014-12-12 at 23:15 +0800, Feng Wu wrote:
> Enable VT-d Posted-Interrtups and add a command line
> parameter for it.
>
> Signed-off-by: Feng Wu
Acked-by: David Woodhouse
--
David WoodhouseOpen Source Technology Centre
david.woodho.
On Fri, 2014-12-12 at 23:14 +0800, Feng Wu wrote:
> Implement irq_set_vcpu_affinity for intel_ir_chip.
>
> Signed-off-by: Feng Wu
> Reviewed-by: Jiang Liu
Acked-by: David.Woodhouse assuming a
suitable answer to...
> + vcpu_pi_info = (struct vcpu_data *)vcpu_info;
> + m
71 matches
Mail list logo
