| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home