qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridg


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough
Date: Tue, 1 Jul 2014 21:45:26 +0300

On Tue, Jul 01, 2014 at 09:34:14PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:49:50PM +0100, Stefano Stabellini wrote:
> > On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> > > On 2014/7/1 3:42, Stefano Stabellini wrote:
> > > > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > So how to separate this to specific to xen? Or you mean we 
> > > > > > > > > need to
> > > > > > > > > create an new machine to address this scenario? But actually 
> > > > > > > > > this
> > > > > > > > > is
> > > > > > > > > same as xenfv_machine except for these little codes.
> > > > > > > > 
> > > > > > > > Yes, please create a new machine so that "-M pc" doesn't have 
> > > > > > > > any of
> > > > > > > > these hacks.
> > > > > > > 
> > > > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So 
> > > > > > > I
> > > > > > > think
> > > > > > > even we create a new machine, shouldn't we still call 
> > > > > > > pc_init_pci()?
> > > > > > > 
> > > > > > > > 
> > > > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. 
> > > > > > > > the
> > > > > > > > default).
> > > > > > > > 
> > > > > > > 
> > > > > > > Yes, Xen can use 'pc'.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > Tiejun
> > > > > > 
> > > > > > You are creating a new machine type where the pci host
> > > > > > looks like MCH but a bunch of other things are from i440fx.
> > > > > 
> > > > > Anthony,
> > > > > 
> > > > > Any comments to address this in xen case?
> > > > 
> > > > Having a separate machine for this is reasonable. You can select the
> > > > right one from libxl anyway. From the name point of view I would go with
> > > > "xenigd".
> > > 
> > > Do this mean we need to change something libxl?
> > 
> > Yes: you would need to pass a different -machine option, see
> > tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
> > It would be a pretty small change.
> > 
> > > > Just take a look at xenfv and introduce something similar but specific
> > > > to your IGD PT use case.
> > > > 
> > > 
> > > Which PCIe machine should I refer? i440fx or q35?
> > 
> > I'd say i440fx.
> 
> I have some doubts this can work cleanly, but if you want to attempt
> this, be my guest.
> 
> So what you want is really franken-i440fx which has this fake isa bridge
> and a mixed config from piix and mch.
> The idea seems to be to make existing guests work, in light of this I
> really don't see the point of pushing any guest changes.
> 
> So first step is just to implement these two, they should have nothing
> to do with xen specifically, should work fine on all hosts, with tcg,kvm
> etc. ISA bridge would just appearing as dummy device there.
> Get flags as features for now.
> Optionally, as an extra user-friendly feature, you can add a flag
> that lets you poke at host and get device IDs etc from sysfs there.
> Pls make this a separate patch though, and we'll discuss this
> separately.

Clarification: that's not a promise that it's mergeable if done that
way, we'll have to evaluate the registers that franken-piix overrides
and weight the chances that
1. guest will start poking at more registers in the future
        or
2. piix will want to use them in the future
leading to maintainance problems.

What I saw so far seems too fragile, I hope most of it isn't
actually required.

And this is why I was saying start with an MCH based chipset
instead.


> Same requirement would apply to q35 really - it's not
> specific to i440fx.
> 
> Also please don't push more guest code upstream until qemu has something
> merged or close to being merged.  You are just creating more messy
> configurations that have to be supported.
> 
> 
> > 
> > > Thanks
> > > Tiejun
> > > 
> > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > > 
> > > > > > 
> > > > > > I have some doubts about this combination being worth supporting - 
> > > > > > it
> > > > > > does not seem useful for anything except xen from the code you 
> > > > > > posted,
> > > > > > but maybe you can whittle down the number of places where you poke 
> > > > > > at
> > > > > > the host to make it reasonable: I can imagine that, if you are 
> > > > > > lucky and
> > > > > > the registers that i915 wants to poke to make it work on real 
> > > > > > hardware
> > > > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > > > bridge.  OTOH it would be much more likely if you just start with
> > > > > > something that does have MCH, like Q35, or emulate a newer
> > > > > > machine type.  This is the path that people who wanted
> > > > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > > > 
> > > > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > > > so it needs a separate name.
> > > > > > 
> > > > > 
> > > > 
> > > 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]