search for: paravirtops

I don't think the numbered patch scheme we're using in the paravirtops patch series is going to work very well. It assumes that we've got the patch order of all the existing patches right, and that we don't need to fit in any new patches between them. I think we'll need the flexibility of rearranging/grouping patches to make them most suited for subm...

...ed some other domUs and the "drift" was also very close to that of the first domU. I also checked another dom0, Here the domUs were "only" out of sync by ~11 seconds. The dom0s are all debian squeeze with Xen 4.0.1-2. The domUs are also debian squeeze and utilizing PV with the ParaVirtOPs in the normal debian linux-image-2.6.32 kernel. I am currently using ntpdate (in cron.hourly) on my dom0s, could this be the problem? Is there a difference in the way ntpdate updates time the way ntpd does? IIRC ntpd updates time continuously, correct? Can someone explain why this would happen. C...

...been published at: http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg This kernel has been the recipient of extensive testing and performance optimization and is actively maintained with the latest stable drivers. There is ongoing work to merge patches which are not currently upstream into the paravirtops tree or to remove the need for those which are not upstreamable. In order to avoid further divergence we would ask that any submissions to this tree take the form of a backport from something which is already committed to the pvops kernel. XCP will be moving to 2.6.32 the based PVops kernel once...

...been published at: http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg This kernel has been the recipient of extensive testing and performance optimization and is actively maintained with the latest stable drivers. There is ongoing work to merge patches which are not currently upstream into the paravirtops tree or to remove the need for those which are not upstreamable. In order to avoid further divergence we would ask that any submissions to this tree take the form of a backport from something which is already committed to the pvops kernel. XCP will be moving to 2.6.32 the based PVops kernel once...

Is it OK for section .parainstructions to reference exit.text? I'm seeing: WARNING: drivers/net/hamradio/scc.o - Section mismatch: reference to .exit.text: from .parainstructions after '' (at offset 0x0) WARNING: drivers/net/hamradio/scc.o - Section mismatch: reference to .exit.text: from .parainstructions after '' (at offset 0x8) If that's OK, we need a small patch to

Is it OK for section .parainstructions to reference exit.text? I'm seeing: WARNING: drivers/net/hamradio/scc.o - Section mismatch: reference to .exit.text: from .parainstructions after '' (at offset 0x0) WARNING: drivers/net/hamradio/scc.o - Section mismatch: reference to .exit.text: from .parainstructions after '' (at offset 0x8) If that's OK, we need a small patch to

Rusty Russell wrote: > Chris: [RFC PATCH 12/33] Change __FIXADDR_TOP to leave room for the hypervisor. > - Replace with dynamic (Geerd) patch, put in paravirt_ops structure. > I'm looking at this, and I'm not sure that there needs to be a void (*set_fixmap_top)(unsigned long top) entry in paravirt ops. It seems to me that the hypervisor's init code can call the

I've updated the patches at http://ozlabs.org/~rusty/paravirt/?mf=33ba6c4fce13;path=/ to carve out the basic shape of how I see all this fitting together. These patches implement an initial set of Xen paravirt ops, as well as adapting head.S to set up a Xen-specific entrypoint. The head.S code does absolutely minimal setup, and then calls xen_start_kernel(). This installs the Xen