similar to: [ANNOUNCE] paravirt_ops i686 Fedora rawhide kernel packages

Make paravirt-ops be a pure function pointer struct; we already have assembly code which uses arithmetic by 4 bytes, which means arbitrary structures are not possible here, and they are not needed. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r a6889086a657 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Thu Apr 19 15:44:49 2007 -0700 +++

Make paravirt-ops be a pure function pointer struct; we already have assembly code which uses arithmetic by 4 bytes, which means arbitrary structures are not possible here, and they are not needed. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r a6889086a657 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Thu Apr 19 15:44:49 2007 -0700 +++

Hi all, I'm pleased to announce a Xen paravirt_ops kernel available for testing at http://xenbits.xensource.com/ext/paravirt_ops/. These kernels are based on this morning's 2.6.21, along with all the paravirt_ops + Xen patches. The pre-built i386 kernel RPM is based on the FC6 configuration, and it has both Xen and VMI paravirt_ops support enabled. Unfortunately the RPM is a bit rough,

Hi all, I'm pleased to announce a Xen paravirt_ops kernel available for testing at http://xenbits.xensource.com/ext/paravirt_ops/. These kernels are based on this morning's 2.6.21, along with all the paravirt_ops + Xen patches. The pre-built i386 kernel RPM is based on the FC6 configuration, and it has both Xen and VMI paravirt_ops support enabled. Unfortunately the RPM is a bit rough,

Hi all, I'm pleased to announce a Xen paravirt_ops kernel available for testing at http://xenbits.xensource.com/ext/paravirt_ops/. These kernels are based on this morning's 2.6.21, along with all the paravirt_ops + Xen patches. The pre-built i386 kernel RPM is based on the FC6 configuration, and it has both Xen and VMI paravirt_ops support enabled. Unfortunately the RPM is a bit rough,

Mails to chrisw at sous-sol.org are not deliverable since several months. Drop him as PARAVIRT_OPS maintainer. Signed-off-by: Juergen Gross <jgross at suse.com> --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d85c08956875..af0cb69f6a3e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10179,7 +10179,6 @@ F: Documentation/parport*.txt

Mails to chrisw at sous-sol.org are not deliverable since several months. Drop him as PARAVIRT_OPS maintainer. Signed-off-by: Juergen Gross <jgross at suse.com> --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d85c08956875..af0cb69f6a3e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10179,7 +10179,6 @@ F: Documentation/parport*.txt

From: "Luis R. Rodriguez" <mcgrof at suse.com> The general documentation we have for pv_ops is currenty present on the IA64 docs, but since this documentation covers IA64 xen enablement and IA64 Xen support got ripped out a while ago through commit d52eefb47 present since v3.14-rc1 lets just simplify, generalize and move the pv_ops documentation to a shared place. Cc: Isaku

From: "Luis R. Rodriguez" <mcgrof at suse.com> The general documentation we have for pv_ops is currenty present on the IA64 docs, but since this documentation covers IA64 xen enablement and IA64 Xen support got ripped out a while ago through commit d52eefb47 present since v3.14-rc1 lets just simplify, generalize and move the pv_ops documentation to a shared place. Cc: Isaku

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we: 1. replace get_scheduled_cycles with sched_clock 2. hoist cycles_2_ns

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we: 1. replace get_scheduled_cycles with sched_clock 2. hoist cycles_2_ns

Acked-by: Chris Wright <chrisw at redhat.com> ;) thanks, -chris On Oct 26, 2017 7:41 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote: > Chris CC'd: He wasn't that hard to find. > > (linkedin says he's CTO of RedHat now. I feel like an underachiever!) > > Cheers, > Rusty. > > Juergen Gross <jgross at suse.com> writes: >

Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> > > --- > > diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c Maintainers are apparently those under "PARAVIRT_OPS INTERFACE". CCs added. > index c12720d..e3ce5c8 100644 > --- a/arch/i386/kernel/vmi.c > +++ b/arch/i386/kernel/vmi.c > @@ -235,7 +235,7 @@ static

Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> > > --- > > diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c Maintainers are apparently those under "PARAVIRT_OPS INTERFACE". CCs added. > index c12720d..e3ce5c8 100644 > --- a/arch/i386/kernel/vmi.c > +++ b/arch/i386/kernel/vmi.c > @@ -235,7 +235,7 @@ static

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement