linux-kernel - Re: [Qemu-devel] [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKgT0UeXeq+GQo1ak9wUEQqzLvE+LN=5tAvZoTtSua1=X3R55A@mail.gmail.com>
Date:	Thu, 9 Jun 2016 08:39:33 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Zhou Jie <zhoujie2011@...fujitsu.com>
Cc:	Alex Duyck <aduyck@...antis.com>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Lan Tianyu <tianyu.lan@...el.com>,
	Yang Zhang <yang.zhang.wz@...il.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	kvm@...r.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	qemu-devel@...gnu.org, Alexander Graf <agraf@...e.de>,
	"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
	Izumi, Taku/泉 拓 
	<izumi.taku@...fujitsu.com>
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] x86: Add support for guest DMA dirty
 page tracking

On Thu, Jun 9, 2016 at 3:14 AM, Zhou Jie <zhoujie2011@...fujitsu.com> wrote:
> TO Alex
> TO Michael
>
>    In your solution you add a emulate PCI bridge to act as
>    a bridge between direct assigned devices and the host bridge.
>    Do you mean put all direct assigned devices to
>    one emulate PCI bridge?
>    If yes, this maybe bring some problems.
>
>    We are writing a patchset to support aer feature in qemu.
>    When assigning a vfio device with AER enabled, we must check whether
>    the device supports a host bus reset (ie. hot reset) as this may be
>    used by the guest OS in order to recover the device from an AER
>    error.
>    QEMU must therefore have the ability to perform a physical
>    host bus reset using the existing vfio APIs in response to a virtual
>    bus reset in the VM.
>    A physical bus reset affects all of the devices on the host bus.
>    Therefore all physical devices affected by a bus reset must be
>    configured on the same virtual bus in the VM.
>    And no devices unaffected by the bus reset,
>    be configured on the same virtual bus.
>
>    http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg02989.html
>
> Sincerely,
> Zhou Jie

That makes sense, but I don't think you have to worry much about this
at this point at least on my side as this was mostly just theory and I
haven't had a chance to put any of it into practice as of yet.

My idea has been evolving on this for a while.  One thought I had is
that we may want to have something like an emulated IOMMU and if
possible we would want to split it up over multiple domains just so we
can be certain that the virtual interfaces and the physical ones
existed in separate domains.  In regards to your concerns perhaps what
we could do is put each assigned device into its own domain to prevent
them from affecting each other.  To that end we could probably break
things up so that each device effectively lives in its own PCIe slot
in the emulated system.  Then when we start a migration of the guest
the assigned device domains would then have to be tracked for unmap
and sync calls when the direction is from the device.

I will keep your concerns in mind in the future when I get some time
to look at exploring this solution further.

- Alex