From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axuaV-0000eL-4J for qemu-devel@nongnu.org; Wed, 04 May 2016 07:03:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axuZu-0003IS-PA for qemu-devel@nongnu.org; Wed, 04 May 2016 07:03:21 -0400 Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:34337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axuZt-00039d-CA for qemu-devel@nongnu.org; Wed, 04 May 2016 07:02:50 -0400 Received: by mail-wm0-x243.google.com with SMTP id n129so9581966wmn.1 for ; Wed, 04 May 2016 04:02:35 -0700 (PDT) References: <1461969763-5193-1-git-send-email-davidkiarie4@gmail.com> <572992D1.7090408@web.de> <5729A725.9010009@gmail.com> <5729D5B8.1010001@gmail.com> From: David Kiarie Message-ID: <5729D6BB.2060508@gmail.com> Date: Wed, 4 May 2016 14:02:19 +0300 MIME-Version: 1.0 In-Reply-To: <5729D5B8.1010001@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [V9 0/4] AMD IOMMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Valentine Sinitsyn Cc: Jan Kiszka , QEMU Developers , "Michael S. Tsirkin" , Peter Xu , Marcel Apfelbaum , imammedo@redhat.com On 04/05/16 13:58, Valentine Sinitsyn wrote: > On 04.05.2016 15:51, David Kiarie wrote: >> On Wed, May 4, 2016 at 10:39 AM, Valentine Sinitsyn >> wrote: >>> Hi everyone, >>> >>> On 04.05.2016 12:05, David Kiarie wrote: >>>> >>>> On Wed, May 4, 2016 at 9:12 AM, Jan Kiszka wrote: >>>>> >>>>> On 2016-04-30 00:42, David Kiarie wrote: >>>>>> >>>>>> These series adds AMD IOMMU support to Qemu. It's currently in >>>>>> the 9th >>>>>> version. >>>>>> >>>>>> In this series I have (hopefully) addressed all the comments made >>>>>> in the >>>>>> previous version. >>>>>> I have also tested and successfully passed-through PCI device 'ac97' >>>>>> with more devices to be tested. >>>>>> >>>>> >>>>> I've done some basic testing with a Jailhouse setup and found it >>>>> working. The ACPI table is now properly parsed and the DMA >>>>> remapping was >>>>> not disturbing the system after Jailhouse was activated. >>>>> >>>>> However, it was also still not intervening after I started to corrupt >>>>> the configuration, removed DMA target properties from most of the >>>>> RAM or >>>>> dropped PCI devices. >>> >>> Please also remember that unlisted devices go without translation. >>> To "mute" >>> the device, set V, TV, the DomainId, and zero everything else in the >>> DTE. >>> >>>> >>>> This means you're invalidating DTEs ? >>>> >>>>> >>>>> You are not dropping invalid remapping requests, are you? >>>>> According to >>>>> the logs, you are detecting them at least: >>>>> >>>>> (amd-iommu)amd_iommu_get_dte: Device Table at 0x3b0d4000 >>>>> (amd-iommu)amd_iommu_get_dte: Pte entry at 0x0 is invalid >>>>> (amd-iommu)amd_iommu_translate: devid: 00:02.0 gpa 0x32f39480 hpa >>>>> 0x32f39000 >>>>> >>>>> It's a bit hard to test right now if remapping is actually properly >>>>> working in all important cases if you do not reject invalid ones. >>> >>> My understanding is that you should generate an IO_PAGE_FAULT event >>> and drop >>> the request. This doesn't apply to ATS, which is a bit trickier, but we >>> don't address ATS in this patch series anyway, do we? >> >> My next question is what you mean by 'reject' and 'drop'. In I >> encounter an invalid PTE/DTE I don't translate the gpa, it just become >> the hpa which is what is happening above. > What happens if you just ignore the request? I mean, what if you don't > forward it to anywhere else in QEMU, just log this event and return? Am guessing this should have something to do with pci abort which, last time I tried, wasn't aborting at request. I will look at it again. > > > Valentine > >> >>> >>> Valentine