This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] upstream merge status for 2.6.35, .36?

 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.


Xen-devel mailing list