Re: upstream merge status for 2.6.35, .36?

[Jeremy Fitzhardinge <jeremy@goop.org>]

  On 08/07/2010 03:50 PM, Josip Rodin wrote:
> OK, so PV PCI pass-through and PV ticket locks are at least definitely
> planned to be submitted for inclusion in .37?

PV ticket locks are very much experimental/RFC at the moment.  I'm 
mostly concerned about possible overhead when running the kernel native.

> I skimmed the previous two dom0 upstreaming to-do lists in presentations,
> and I'd appreciate it if someone could provide some more current information
> regarding them:
>
> * is the code in xen/dom0/acpi-next and xen/dom0/apic-next, nowadays part
>    of xen/stable, upstreamable per se, or are there still parts of that
>    which would be objectionable upstream?

A useful chunk of the APIC stuff went upstream with Stefano's pv-hvm 
patches.  Not the actual interrupt setup stuff, but a lot of the 
infrastructure it requires.  pcifront will take a lot of the rest of it up.

I need to re-review the state of ACPI to work out how much could go up.  
It has certainly improved over time, but it hasn't got an ack from the 
ACPI maintainers.  On the other hand, it isn't absolutely crucial to get 
dom0 working.

> * is the PAT issue resolved? I can't seem to find the patch disabling it
>    in xen/stable any more, so it looks like it's no longer an issue, but
>    maybe I just looked in the wrong place.

PAT is no longer disabled, and often works - radeon seems to be the big 
problem.  Konrad has a set of patches to make DRM/KMS work on a very 
wide range of cards, with full PAT support.  But unfortunately at the 
cost of adding more pvops calls on various mm critical paths, such as 
pagefault.  We may have to live with that for now.

> * what happened to the PG_FOREIGN issue - xen/stable still has it in the
>    original (.18) form? From what I can see, it's for marking memory pages
>    for/from some other Xen domain, presumably for netback performance etc.
>    Could this be e.g. ripped out in a separate branch that would just allow
>    for the upstreaming of the rest of dom0 code?

Probably the simplest way to deal with it is to do simplified forms of 
netback and blkback/tap which copy rather than keep mappings of granted 
pages hanging around.  If zero copy is still desirable (which is 
conventional wisdom, but worth verifying in practice), then we can 
maintain out-of-tree patches adding it until a suitably upstreamable 
form can be developed.  One thing to bear in mind is that KVM/virtio 
have more or less the same set of problems to solve, so with luck we can 
find something useful to both.

     J