search for: pvfull

...t; paravirt_types_full.h which will contain the necessary implementation > parts of the pv guest specific paravirt functions. Is it not possible to just 'ifdef CONFIG_PARAVIT_FULL' the (ir)relevant parts of paravirt.[ch] and paravirt_types.c? Separating structures and files into pv and pvfull seems somewhat arbitrary (.flush_tlb_others in patch 8 being a good example of one type of guest deciding to use something that normally would be considered part of a pvfull-type structure). -boris

...t; paravirt_types_full.h which will contain the necessary implementation > parts of the pv guest specific paravirt functions. Is it not possible to just 'ifdef CONFIG_PARAVIT_FULL' the (ir)relevant parts of paravirt.[ch] and paravirt_types.c? Separating structures and files into pv and pvfull seems somewhat arbitrary (.flush_tlb_others in patch 8 being a good example of one type of guest deciding to use something that normally would be considered part of a pvfull-type structure). -boris

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,