Re: [Xen-devel] Xen 4.2 Release Plan / TODO

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-03-22 at 10:08 +0000, George Dunlap wrote:
> On Thu, Mar 22, 2012 at 9:53 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Thu, 2012-03-22 at 09:35 +0000, George Dunlap wrote:
> >> On Mon, Mar 19, 2012 at 10:57 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> >> wrote:
> >> >      * xl compatibility with xm:
> >> >              * feature parity wrt driver domain support (George Dunlap)
> >> I just discovered (while playing with driver domains) that xl is
> >> missing one bit of feature parity with xm for pci passthrough for PV
> >> guests -- and that's the "pci quirk" config file support.  I'm going
> >> to ask Intel if they have an interest in porting it over; I think it
> >> should at least be a "nice-to-have", and it may be a low-level
> >> blocker, as a lot of devices won't work passed through without it.
> >
> > This is the stuff in tools/python/xen/xend/server/pciquirk.py ?
> >
> > pciback in upstream doesn't mention "quirk" which suggests no support
> > for the necessary sysfs node either?
> 
> Ah, interesting -- that's worth tracking down.  Maybe there's a better
> way to deal with quirks?  Or maybe it just hasn't been upstreamed yet
> (or perhaps even implemented in pvops?).  I'm using the Debian squeeze
> 2.6.32-5-xen-686 kernel.

I told a lie -- the code does seem to be there in mainline
(drivers/xen/xen-pciback/conf_space_quirks.c et al). Not sure how grep
missed it.

Does anyone know what the actual purpose/function of the single defined
quirk is? 10845:df80de098d15 which introduces it doesn't really say,
it's just a bunch of magic register frobbing as far as I'm concerned.

I guess you have a tg3 and are suffering from this exact quirk?

It's an awful lot of scaffolding on both the userspace and kernel side
to support a generic quirks system which has had exactly one quirk since
it was introduced in mid 2006. Perhaps we should just address the
specific tg3 issue directly?

> 
> > tools/examples/xend-pci-quirks.sxp  seems to only have a quirk for a
> > single card?
> 
> Yes, well I could add two more cards just from experience w/ one of my
> test boxen. :-)
> 
> > I don't think we want to implement an SXP parser for xl/libxl so if this
> > is reimplemented I think a different format should be used.
> 
> Since we're using yajl anyway, JSON might not be a bad option.
> 
> Anyway, I'll ping the Intel guy who recently posted a patch to libxl_pci.c.
> 
>  -George
> 
> >
> > Anyway, I'll put this onto the list.
> >
> > Ian
> >
> >>
> >> >              * xl support for "rtc_timeoffset" and "localtime" (Lin
> >> >                Ming, Patches posted)
> >> >      * More formally deprecate xm/xend. Manpage patches already in
> >> >        tree. Needs release noting and communication around -rc1 to
> >> >        remind people to test xl.
> >> >      * Domain 0 block attach & general hotplug when using qdisk backend
> >> >        (need to start qemu as necessary etc) (Stefano S)
> >> >      * file:// backend performance. qemu-xen-tradition's qdisk is quite
> >> >        slow & blktap2 not available in upstream kernels. Need to
> >> >        consider our options:
> >> >              * qemu-xen's qdisk is thought to be well performing but
> >> >                qemu-xen is not yet the default. Complexity arising from
> >> >                splitting qemu-for-qdisk out from qemu-for-dm and
> >> >                running N qemu's.
> >> >              * potentially fully userspace blktap could be ready for
> >> >                4.2
> >> >              * use /dev/loop+blkback. This requires loop driver AIO and
> >> >                O_DIRECT patches which are not (AFAIK) yet upstream.
> >> >              * Leverage XCP's blktap2 DKMS work.
> >> >              * Other ideas?
> >> >      * Improved Hotplug script support (Roger Pau MonnÃ, patches
> >> >        posted)
> >> >      * Block script support -- follows on from hotplug script (Roger
> >> >        Pau MonnÃ)
> >> >
> >> > hypervisor, nice to have:
> >> >      * solid implementation of sharing/paging/mem-events (using work
> >> >        queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> >> >              * "The last patch to use a waitqueue in
> >> >                __get_gfn_type_access() from Tim works.  However, there
> >> >                are a few users who call __get_gfn_type_access with the
> >> >                domain_lock held. This part needs to be addressed in
> >> >                some way."
> >> >      * Sharing support for AMD (Tim, Andres).
> >> >      * PoD performance improvements (George Dunlap)
> >> >
> >> > tools, nice to have:
> >> >      * Configure/control paging via xl/libxl (Olaf Herring, lots of
> >> >        discussion around interface, general consensus reached on what
> >> >        it should look like)
> >> >      * Upstream qemu feature patches:
> >> >              * Upstream qemu PCI passthrough support (Anthony Perard,
> >> >                patches sent)
> >> >              * Upstream qemu save restore (Anthony Perard, Stefano
> >> >                Stabellini, patches sent, waiting for upstream ack)
> >> >      * Nested-virtualisation. Currently "experimental". Likely to
> >> >        release that way.
> >> >              * Nested SVM. Tested in a variety of configurations but
> >> >                still some issues with the most important use case (w7
> >> >                XP mode) [0]  (Christoph Egger)
> >> >              * Nested VMX. Needs nested EPT to be genuinely useful.
> >> >                Need more data on testedness etc (Intel)
> >> >      * Initial xl support for Remus (memory checkpoint, blackholing)
> >> >        (Shriram, patches posted, blocked behind qemu save restore
> >> >        patches)
> >> >      * xl compatibility with xm:
> >> >              * xl support for autospawning vncviewer (vncviewer=1 or
> >> >                otherwise) (Goncalo Gomes)
> >> >              * support for vif "rate" parameter (Mathieu GagnÃ)
> >> >
> >> > [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
> >> >
> >> >
> >> > _______________________________________________
> >> > Xen-devel mailing list
> >> > Xen-devel@xxxxxxxxxxxxx
> >> > http://lists.xen.org/xen-devel
> >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel