[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa
From: |
Zhang, Yang Z |
Subject: |
Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge |
Date: |
Fri, 6 Jun 2014 03:06:12 +0000 |
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.
> 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.
>
> 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
- Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Stefano Stabellini, 2014/06/02
- Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Paolo Bonzini, 2014/06/03
- Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Stefano Stabellini, 2014/06/03
- Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Paolo Bonzini, 2014/06/03
- Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Stefano Stabellini, 2014/06/03
- Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Tian, Kevin, 2014/06/03
- Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, George Dunlap, 2014/06/03
- Re: [Qemu-devel] [Xen-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Sander Eikelenboom, 2014/06/03
- Re: [Qemu-devel] [Xen-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Paolo Bonzini, 2014/06/03
- Re: [Qemu-devel] [Xen-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge, Sander Eikelenboom, 2014/06/03
Re: [Qemu-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge,
Zhang, Yang Z <=