similar to: [PATCH 0/3] KVM paravirt_ops implementation

Hi, This patch series is an update of my previous paravirt_ops patches. They are loosely based on Ingo's original paravirt_ops implementation for KVM. Some of the changes since the last series include: 1) Switch to using CPUID 0x40000000 instead of using MSR writes to discover shared memory area 2) Attempt to deal with SMP guests 3) Support for generic CR read caching 4) Support for

Hi, This patch series is an update of my previous paravirt_ops patches. They are loosely based on Ingo's original paravirt_ops implementation for KVM. Some of the changes since the last series include: 1) Switch to using CPUID 0x40000000 instead of using MSR writes to discover shared memory area 2) Attempt to deal with SMP guests 3) Support for generic CR read caching 4) Support for

Hi, This is an update to the paravirt_ops KVM backend series. I've made a number of changes and attempted to incorporate all the feedback from the last review. Some highlights: 1) Clean up the paravirt time source patch to use a more Xen-like model 2) Change the hypercall queueing to pass a PA on the flush hypercall 3) Add MMU support for release_{pt,pd} and TLB flush 4) Use KVM specific

Hi, This is an update to the paravirt_ops KVM backend series. I've made a number of changes and attempted to incorporate all the feedback from the last review. Some highlights: 1) Clean up the paravirt time source patch to use a more Xen-like model 2) Change the hypercall queueing to pass a PA on the flush hypercall 3) Add MMU support for release_{pt,pd} and TLB flush 4) Use KVM specific

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi, Please find below the proposal for the generic use of cpuid space allotted for hypervisors. Apart from this cpuid space another thing worth noting would be that, Intel & AMD reserve the MSRs from 0x40000000 - 0x400000FF for software use. Though the proposal doesn't talk about MSR's right now, we should be aware of these reservations as we may want to extend the way we use CPUID to

Hi, Please find below the proposal for the generic use of cpuid space allotted for hypervisors. Apart from this cpuid space another thing worth noting would be that, Intel & AMD reserve the MSRs from 0x40000000 - 0x400000FF for software use. Though the proposal doesn't talk about MSR's right now, we should be aware of these reservations as we may want to extend the way we use CPUID to

On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini <pbonzini at redhat.com> wrote: > >> > Actually, that MSR address range has been reserved for that purpose, along >> > with: >> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal) >> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID) >> >> I don't know whether this is

On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini <pbonzini at redhat.com> wrote: > >> > Actually, that MSR address range has been reserved for that purpose, along >> > with: >> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal) >> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID) >> >> I don't know whether this is

On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com> wrote: >> >> >>> -----Original Message----- >>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo >>> Bonzini >>> Sent: Thursday, September 18, 2014 10:18

On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com> wrote: >> >> >>> -----Original Message----- >>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo >>> Bonzini >>> Sent: Thursday, September 18, 2014 10:18

I'm running a Samba server on Raspbian and observing that Samba during idle periods is constantly (every minute) writing to HDD (maybe doing some journaling?) what causes the HDD to constantly spin and never standby: root at rpi:~# pidstat -dl 20 Linux 4.4.50-v7+ (localhost) 11/07/2018 _armv7l_ (4 CPU) 04:10:08 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 04:10:28 AM

Am 07.11.18 um 09:54 schrieb Rowland Penny via samba: > On Wed, 7 Nov 2018 05:45:45 +0300 > Albert Berger via samba <samba at lists.samba.org> wrote: > >> I'm running a Samba server on Raspbian and observing that Samba >> during idle periods is constantly (every minute) writing to HDD >> (maybe doing some journaling?) what causes the HDD to constantly spin

Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This complicates each paravirt backend, since it needs to deal with all the possible state transitions, handling flushing, etc. In particular, flushing is quite distinct from the other 4 functions,

Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This complicates each paravirt backend, since it needs to deal with all the possible state transitions, handling flushing, etc. In particular, flushing is quite distinct from the other 4 functions,

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] 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

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] 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

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This