From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsnti-0000EG-A9 for qemu-devel@nongnu.org; Fri, 06 Jun 2014 02:45:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsntZ-0005Rj-8i for qemu-devel@nongnu.org; Fri, 06 Jun 2014 02:45:06 -0400 Received: from mail-qg0-x230.google.com ([2607:f8b0:400d:c04::230]:44817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsntZ-0005Re-49 for qemu-devel@nongnu.org; Fri, 06 Jun 2014 02:44:57 -0400 Received: by mail-qg0-f48.google.com with SMTP id i50so3561037qgf.7 for ; Thu, 05 Jun 2014 23:44:56 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53916363.8080706@redhat.com> Date: Fri, 06 Jun 2014 08:44:51 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1401440369-29929-1-git-send-email-tiejun.chen@intel.com> <1401440369-29929-3-git-send-email-tiejun.chen@intel.com> <538D8B59.4070105@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Zhang, Yang Z" , "Chen, Tiejun" , "anthony.perard@citrix.com" , "stefano.stabellini@eu.citrix.com" , "mst@redhat.com" , "Kelly.Zytaruk@amd.com" Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "Kay, Allen M" , "qemu-devel@nongnu.org" , "anthony@codemonkey.ws" Il 06/06/2014 05:06, Zhang, Yang Z ha scritto: > Paolo Bonzini wrote on 2014-06-03: >> Il 30/05/2014 10:59, Tiejun Chen ha scritto: >>> +static int create_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev) >>> +{ >>> + struct PCIDevice *dev; >>> + >>> + char rid; >>> + >>> + dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "intel-pch-isa-bridge"); >> >> This is really a huge hack. You're going to have two ISA bridge devices >> in the machine, with the BIOS imagining that the "good" one is at 1f.0 > > Definitely. So how about expose a fake device at 00:1f.0 but not Isa Bridge? I have discussion with gfx driver developer, it is ok for them to check the device on 00:1f.0 no matter what device it is. That would be slightly better. >> and the ACPI tables actually describing the other one. But the PCI >> device at 1f.0 remains there and a driver in the OS could catch it---not >> just intel_detect_pch---and if you want to add such a hack it should be >> done in the Xen management layers. >> >> If possible, the host bridge patches are even worse. If you change the >> vendor and device ID while keeping the registers of the i440FX you're >> going to get conflicts or break firmware badly; TianoCore and SeaBIOS >> both expect the normal i440FX vendor and device IDs, for example. > > I only see the class id is changed but not vendor and device id. Yes, and the class ID is a typo probably. But when the guest reads the vendor and device ID, igd_pci_read passes it through. So effectively it changes, if I read the code correctly. Paolo >> >> The hardcoded list of offsets is also not acceptable. It is also not >> clear who is accessing the registers, whether the BIOS or the driver. >> For Linux, a cursory look at the driver shows that it only accesses >> 0x50/0x52 of the listed offsets, but also 0x44/0x48 ("MCH BAR"), what >> happens if that code path is encountered? > > Will have a double check. > >> >> The main problem with IGD passthrough is the incestuous (and that's a >> euphemism) relationship between the MCH, PCH and graphics driver. It >> may make sense at the hardware level, but for virtualization it doesn't. >> A virt-specific driver for GPU command passthrough (with aid from the >> kernel driver, but abstracting all the MCH/PCH-dependent details) would >> make much more sense. > > Agree. But it is too hard. > >> >> It's really not your fault, there's not much you can do given the >> hardware architecture. But I don't think this code can be accepted >> upstream, sorry. >> >> Paolo > > > Best regards, > Yang > > > >