[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [V6 0/4] AMD IOMMU
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [V6 0/4] AMD IOMMU |
Date: |
Tue, 1 Mar 2016 21:17:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2016-03-01 21:11, Michael S. Tsirkin wrote:
> On Tue, Mar 01, 2016 at 03:00:09PM +0100, Jan Kiszka wrote:
>> On 2016-03-01 14:48, Jan Kiszka wrote:
>>> There is likely no way around write-protecting the IOMMU page tables (in
>>> KVM mode) once we evaluated and cached them somewhere.
>>
>> I mean, when in kvm mode AND having something that caches enabled, of
>> course.
>
> Just write-protecting won't be enough either, since
> the moment you remove the protection, all bets are off,
> and if you don't, guest will start from the same point
> when you re-enter and fault again.
We would not remove protection as long as the entry is in use by the
IOMMU. There should be no difference from shadow MMU logic here: trap
and emulate the write.
>
> What this seems to call for is a new kind of protection
> where yes PTE is write protected, but instead of
> making PTE writeable (or killing guest)
> KVM handles it as an MMIO: emulates the write and then skips the instruction.
>
> Emulation can be in kernel, just writing into guest memory
> on behalf of the guest - with some kind of notifier
> to flush the vfio cache - or instead it can exit to userspace
> and have QEMU handle it like MMIO and write into guest memory.
Exactly, but that's nothing new, is it? It's "just" slow, like other
shadow MMUs.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [V6 0/4] AMD IOMMU, Jan Kiszka, 2016/03/01
Re: [Qemu-devel] [V6 0/4] AMD IOMMU, David Kiarie, 2016/03/02