On Thu, 2023-10-19 at 08:40 -0700, Sean Christopherson wrote:
>
> > Normally, it should be up to the hypervisor to tell the guest which
> > clock to use, i.e. if TSC is reliable or not. Let me put my question
> > this way: if TSC on the particular host is good for everything, why
> > does the hype
On 6 May 2023 09:56:35 BST, Hao Chen wrote:
>In the current code, if the maximum MTU supported by the virtio net hardware
>is 9000, the default MTU of the virtio net driver will also be set to 9000.
>When sending packets through "ping -s 5000", if the peer router does not
>support negotiatin
On Tue, 2022-02-22 at 01:31 -0500, Michael S. Tsirkin wrote:
> On Mon, Feb 21, 2022 at 05:18:48PM +0000, David Woodhouse wrote:
> >
> > [dwoodhou@i7 virtio]$ sudo ~/virtio_test
> > Detected virtual address range 0x1000-0x7000
> > spurious wakeups: 0x0 started=
On Mon, 2022-02-21 at 18:02 +0100, Stefano Garzarella wrote:
> On Mon, Feb 21, 2022 at 04:15:22PM +0000, David Woodhouse wrote:
> > As things stand, an application which wants to use vhost with a trivial
> > 1:1 mapping of its virtual address space is forced to jump through hoop
e same
way as https://gitlab.com/openconnect/openconnect/-/commit/443edd9d8826
does.
This is untested as I can't actually get virtio_test to work at all; it
just seems to deadlock on a spinlock. But it's getting the right answer
for the virtio range on x86_64 at least.
Signed-off
On Tue, 2020-12-15 at 16:42 +, Wei Liu wrote:
> On Tue, Dec 15, 2020 at 04:25:03PM +0100, Enrico Weigelt, metux IT consult
> wrote:
> > On 03.12.20 00:22, Wei Liu wrote:
> >
> > Hi,
> >
> > > I don't follow. Do you mean reusing /dev/kvm but with a different set of
> > > APIs underneath? I do
On Tue, 2020-11-24 at 17:07 +, Wei Liu wrote:
> We will soon use the same structure to handle IO-APIC interrupts as
> well. Introduce an enum to identify the source and a data structure for
> IO-APIC RTE.
>
> While at it, update pci-hyperv.c to use the enum.
>
> No functional change.
>
> Sig
On Fri, 2016-12-09 at 19:22 +0100, Christoph Hellwig wrote:
> We'll need a bit of a wieder audience for this I think..
>
> On Wed, Dec 07, 2016 at 05:11:28PM -0800, Bart Van Assche wrote:
> > Additionally, introduce set_dma_ops(). A later patch will introduce a
> > call to that function in the RDM
On Thu, 2016-04-28 at 18:37 +0300, Michael S. Tsirkin wrote:
> OK, so for intel, it seems that it's enough to set
> pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO;
> for the device.
Yes, currently. Although that's vile. In fact what we *want* to happen
is for the intel-iommu code simply
On Thu, 2016-04-28 at 17:34 +0300, Michael S. Tsirkin wrote:
> I see work-arounds for broken IOMMUs but not for
> individual devices. Could you point me to a more specific
> example?
I think the closest example is probably quirk_ioat_snb_local_iommu().
If we see this particular device, we *know*
On Wed, 2016-04-27 at 21:17 +0300, Michael S. Tsirkin wrote:
>
> > Because it's a dirty hack in the *wrong* place.
>
> No one came up with a better one so far :(
Seriously?
Take a look at drivers/iommu/intel-iommu.c. It has quirks for all kinds
of shitty devices that have to be put in passthrou
On Wed, 2016-04-27 at 18:05 +0300, Michael S. Tsirkin wrote:
>
> I really don't get it.
>
> There's exactly one device that works now and needs the work-around and
> so that we need to support, and that is virtio. It happens to have
> exactly the same issue on all platforms.
False. We have other
ng no-op DMA ops for the
appropriate devices, perhaps.
Then we can look at giving qemu a way to properly indicate which
devices it actually does DMA mapping for, so we can remove those
heuristic assumptions.
But that flag does *not* live in the virtio host←→guest ABI.
--
David Woodhou
On Tue, 2016-04-19 at 19:20 +0300, Michael S. Tsirkin wrote:
>
> > I thought that PLATFORM served that purpose. Woudn't the host
> > advertise PLATFORM support and, if the guest doesn't ack it, the host
> > device would skip translation? Or is that problematic for vfio?
>
> Exactly that's probl
On Mon, 2016-04-18 at 19:27 +0300, Michael S. Tsirkin wrote:
> I balk at adding more hacks to a broken system. My goals are
> merely to
> - make things work correctly with an IOMMU and new guests,
> so people can use userspace drivers with virtio devices
> - prevent security risks when guest kern
On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote:
>
> > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that
> > its own operating system's IOMMU code is expected to be broken, and
> > that the virtio driver should eschew the DMA API?
>
> No - it tells guest that e.g.
On Mon, 2016-04-18 at 17:23 +0300, Michael S. Tsirkin wrote:
>
> This patch doesn't change DMAR tables, it creates a way for virtio
> device to tell guest "I obey what DMAR tables tell you, you can stop
> doing hacks".
>
> And as PPC guys seem adamant that platform tools there are no good for
> t
On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote:
> I'm not sure I understand the issue. The public API is not about how
> the driver works. It doesn't say "don't use DMA API" anywhere, does it?
> It's about telling device whether to obey the IOMMU and
> about discovering whether a dev
On Mon, 2016-04-18 at 14:47 +0300, Michael S. Tsirkin wrote:
> This adds a flag to enable/disable bypassing the IOMMU by
> virtio devices.
I'm still deeply unhappy with having this kind of hack in the virtio
code at all, as you know. Drivers should just use the DMA API and if
the *platform* wants
On Wed, 2016-02-17 at 11:29 +0200, Michael S. Tsirkin wrote:
>
> I was hoping for an explicit ack from David Woodhouse,
> but I guess the informal "let's not hold this up"
> that was sent on v5 will do.
Apologies; I was working under that assumption too.
--
dwmw2
of
> principle. I'd also like to flip as many arches over as possible, but
> that could be trickier. Let me mull over this.
Let's queue the arch_vring_eschew_dma_api() thing up after this first
batch, and not hold it up any further.
--
David Woodhouse
ffected architectures could provide (as a prelude to fixing it so that
the DMA API does the right thing for *itself*)?
It would be functionally equivalent, but it would help to push the
workarounds to the right place — rather than entrenching them for ever
in tricky "OMG we need to audit what al
pt-
in-simulation issues with VT-d IOMMU covering *some* devices but not
all.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
> 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
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)
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 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 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
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 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),
&
(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
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 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 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 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 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 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 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
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 Sat, 2014-09-20 at 22:48 -0700, Andy Lutomirski wrote:
>
> I'm all for doing this as some kind of bus property, if needed,
> although David Woodhouse may be right that the best solution is to
> *always* have the IOMMU there and to just ask it for an identity map
> if desire
y.
> >
> > Well if there's a way to detect that - that's outside the
> > device, then we probably shouldn't use device-specific
> > interfaces for this capability.
>
> (NB: According to David Woodhouse about ten minutes ago, this should
> work with
42 matches
Mail list logo
