Re: [Xen-devel] [PATCH] xen/scsifront: don't advance ring request pointer in case of error

On 29/11/16 11:19, Juergen Gross wrote: > On 29/11/16 12:14, Jan Beulich wrote: > On 29.11.16 at 11:50, wrote: >>> --- a/drivers/scsi/xen-scsifront.c >>> +++ b/drivers/scsi/xen-scsifront.c >>> @@ -184,8 +184,6 @@ static struct vscsiif_request *scsifront_pre_req(struct >>>

Re: [Xen-devel] [PATCH] xen/scsifront: don't advance ring request pointer in case of error

On 29/11/16 11:19, Juergen Gross wrote: > On 29/11/16 12:14, Jan Beulich wrote: > On 29.11.16 at 11:50, wrote: >>> --- a/drivers/scsi/xen-scsifront.c >>> +++ b/drivers/scsi/xen-scsifront.c >>> @@ -184,8 +184,6 @@ static struct vscsiif_request *scsifront_pre_req(struct >>> vscsifrnt_info

Re: [Xen-devel] [PATCH] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

o avoid this, instead of setting VM_IO use mempolicy that prohibits page > migration (i.e. clear policy's MPOL_F_MOF|MPOL_F_MORON) Reviewed-by: David Vrabel <david.vra...@citrix.com> With the corrected commit message. David

Re: [Xen-devel] [PATCH] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

o avoid this, instead of setting VM_IO use mempolicy that prohibits page > migration (i.e. clear policy's MPOL_F_MOF|MPOL_F_MORON) Reviewed-by: David Vrabel With the corrected commit message. David

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On 10/11/16 17:47, Olaf Hering wrote: > On Thu, Nov 10, Boris Ostrovsky wrote: > >> Are you sure it's this patch that causes the failure? >> >> I commented out '| VM_IO' and still unable to boot with this option. > > Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based: > > +++

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On 10/11/16 17:47, Olaf Hering wrote: > On Thu, Nov 10, Boris Ostrovsky wrote: > >> Are you sure it's this patch that causes the failure? >> >> I commented out '| VM_IO' and still unable to boot with this option. > > Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based: > > +++

Re: [PATCH 00/12] xen: add common function for reading optional value

ith the call of the new function > where appropriate. Acked-by: David Vrabel <david.vra...@citrix.com> Please queue for the next release. David

Re: [PATCH 00/12] xen: add common function for reading optional value

ith the call of the new function > where appropriate. Acked-by: David Vrabel Please queue for the next release. David

Re: [Xen-devel] [PATCH 01/12] xen: introduce xenbus_read_unsigned()

On 31/10/16 16:48, Juergen Gross wrote: > There are multiple instances of code reading an optional unsigned > parameter from Xenstore via xenbus_scanf(). Instead of repeating the > same code over and over add a service function doing the job. Reviewed-by: David Vrabel <david.vra..

Re: [Xen-devel] [PATCH 01/12] xen: introduce xenbus_read_unsigned()

On 31/10/16 16:48, Juergen Gross wrote: > There are multiple instances of code reading an optional unsigned > parameter from Xenstore via xenbus_scanf(). Instead of repeating the > same code over and over add a service function doing the job. Reviewed-by: David Vrabel David

[PATCHv4 2/3] xenfs: replace xenbus and privcmd with symlinks

to be identical to the character device /dev/xen/xenbus so replace the file with a symlink. Similarly, replace /proc/xen/privcmd with a symlink since it should be the same as /dev/xen/privcmd. Signed-off-by: David Vrabel <david.vra...@citrix.com> --- v4: - Make xen_xenbus_fops and xen_privcmd_fops

[PATCHv4 2/3] xenfs: replace xenbus and privcmd with symlinks

to be identical to the character device /dev/xen/xenbus so replace the file with a symlink. Similarly, replace /proc/xen/privcmd with a symlink since it should be the same as /dev/xen/privcmd. Signed-off-by: David Vrabel --- v4: - Make xen_xenbus_fops and xen_privcmd_fops static. --- drivers/xen/privcmd.c

[PATCHv4 1/3] libfs: allow simple_fill_super() to add symlinks

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK. The target is provided in the new "link" field. Signed-off-by: David Vrabel <david.vra...@citrix.com> --- v4: - Use switch for file type. v2: - simplified. --- fs/libfs.c | 27

[PATCHv4 3/3] xenfs: Use proc_create_mount_point() to create /proc/xen

ntpoints in proc but is currently proc-internal. Export this interface to modules, then use it in xenbus when creating /proc/xen. Signed-off-by: Seth Forshee <seth.fors...@canonical.com> Signed-off-by: David Vrabel <david.vra...@citrix.com> --- drivers/xen/xenbus/xenbus_probe.c | 2 +- fs/proc/g

[PATCH v4 0/3] libfs,xenfs: replace /proc/xen/xenbus with a symlink

Using /proc/xen/xenbus can cause deadlocks on the atomic file position mutex since this file should behave like a character device and not a regular file. This is easiest to achive by making it a symlink to the existing /dev/xen/xenbus device. This requires extending simple_fill_super() to add

[PATCHv4 3/3] xenfs: Use proc_create_mount_point() to create /proc/xen

al. Export this interface to modules, then use it in xenbus when creating /proc/xen. Signed-off-by: Seth Forshee Signed-off-by: David Vrabel --- drivers/xen/xenbus/xenbus_probe.c | 2 +- fs/proc/generic.c | 1 + fs/proc/internal.h| 1 - include/linux/proc_fs.h

[PATCH v4 0/3] libfs,xenfs: replace /proc/xen/xenbus with a symlink

Using /proc/xen/xenbus can cause deadlocks on the atomic file position mutex since this file should behave like a character device and not a regular file. This is easiest to achive by making it a symlink to the existing /dev/xen/xenbus device. This requires extending simple_fill_super() to add

[PATCHv4 1/3] libfs: allow simple_fill_super() to add symlinks

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK. The target is provided in the new "link" field. Signed-off-by: David Vrabel --- v4: - Use switch for file type. v2: - simplified. --- fs/libfs.c | 27 --- include/linux/fs.h |

[GIT PULL] xen: xenfs fixes for 4.9-rc2

++ 11 files changed, 24 insertions(+), 22 deletions(-) David Vrabel (2): libfs: allow simple_fill_super() to add symlinks xenfs: replace xenbus and privcmd with symlinks Seth Forshee (1): xenbus: Use proc_create_mount_point() to create /proc/xen -BEGIN PGP SIGNATURE

[GIT PULL] xen: xenfs fixes for 4.9-rc2

++ 11 files changed, 24 insertions(+), 22 deletions(-) David Vrabel (2): libfs: allow simple_fill_super() to add symlinks xenfs: replace xenbus and privcmd with symlinks Seth Forshee (1): xenbus: Use proc_create_mount_point() to create /proc/xen -BEGIN PGP SIGNATURE

[GIT PULL] xen: fixes for 4.9-rc2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc2-tag xen: fixes for 4.9-rc2 - - Advertise control feature flags in xenstore. - - Fix x86 build when XEN_PVHVM is disabled.

[GIT PULL] xen: fixes for 4.9-rc2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc2-tag xen: fixes for 4.9-rc2 - - Advertise control feature flags in xenstore. - - Fix x86 build when XEN_PVHVM is disabled.

Re: [PATCH v3] xenbus: advertize control feature flags

ant feature-flag keys. >> >> Signed-off-by: Paul Durrant <paul.durr...@citrix.com> >> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> >> Cc: David Vrabel <david.vra...@citrix.com> >> Cc: Juergen Gross <jgr...@suse.com> > > Hmm, I'd prefer node

Re: [PATCH v3] xenbus: advertize control feature flags

ant feature-flag keys. >> >> Signed-off-by: Paul Durrant >> Cc: Boris Ostrovsky >> Cc: David Vrabel >> Cc: Juergen Gross > > Hmm, I'd prefer node[] allocated on the stack over dynamic allocation. > > What about something like the following? It will at least

Re: [PATCH v2] xenbus: advertize control feature flags

On 10/10/16 10:43, Paul Durrant wrote: > The Xen docs specify several flags which a guest can set to advertize > which values of the xenstore control/shutdown key it will recognize. > This patch adds code to write all the relevant feature-flag keys. [...] > static int setup_shutdown_watcher(void)

Re: [PATCH v2] xenbus: advertize control feature flags

On 10/10/16 10:43, Paul Durrant wrote: > The Xen docs specify several flags which a guest can set to advertize > which values of the xenstore control/shutdown key it will recognize. > This patch adds code to write all the relevant feature-flag keys. [...] > static int setup_shutdown_watcher(void)

Re: [Xen-devel] [PATCH] xen/x86: Update topology map for PV VCPUs

On 05/10/16 18:09, Boris Ostrovsky wrote: > Early during boot topology_update_package_map() computes > logical_pkg_ids for all present processors. > > Later, when processors are brought up, identify_cpu() updates > these values based on phys_pkg_id which is a function of > initial_apicid. On PV

Re: [Xen-devel] [PATCH] xen/x86: Update topology map for PV VCPUs

On 05/10/16 18:09, Boris Ostrovsky wrote: > Early during boot topology_update_package_map() computes > logical_pkg_ids for all present processors. > > Later, when processors are brought up, identify_cpu() updates > these values based on phys_pkg_id which is a function of > initial_apicid. On PV

[GIT PULL] xen: features and fixes for 4.9-rc0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc0-tag xen: features and fixes for 4.9-rc0 - - Switch to new CPU hotplug mechanism. - - Support driver_override in pciback. - -

[GIT PULL] xen: features and fixes for 4.9-rc0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc0-tag xen: features and fixes for 4.9-rc0 - - Switch to new CPU hotplug mechanism. - - Support driver_override in pciback. - -

Re: [Xen-devel] [PATCH] xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier

On 02/10/16 23:45, Boris Ostrovsky wrote: > xen_cpuhp_setup() calls mutex_lock() which, when CONFIG_DEBUG_MUTEXES > is defined, ends up calling xen_save_fl(). That routine expects > per_cpu(xen_vcpu, 0) to be already initialized. Applied to for-linus-4.9, thanks. David

Re: [Xen-devel] [PATCH] xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier

On 02/10/16 23:45, Boris Ostrovsky wrote: > xen_cpuhp_setup() calls mutex_lock() which, when CONFIG_DEBUG_MUTEXES > is defined, ends up calling xen_save_fl(). That routine expects > per_cpu(xen_vcpu, 0) to be already initialized. Applied to for-linus-4.9, thanks. David

Re: [Xen-devel] [PATCH v3 0/3] xen/pciback: support driver_override

On 22/09/16 09:45, Juergen Gross wrote: > Support the driver_override scheme introduced with commit 782a985d7af2 > ("PCI: Introduce new device binding path using pci_dev.driver_override") Applied to for-linus-4.9, thanks. David

Re: [Xen-devel] [PATCH v3 0/3] xen/pciback: support driver_override

On 22/09/16 09:45, Juergen Gross wrote: > Support the driver_override scheme introduced with commit 782a985d7af2 > ("PCI: Introduce new device binding path using pci_dev.driver_override") Applied to for-linus-4.9, thanks. David

Re: [Xen-devel] [PATCH v2 0/2] Convert to new CPU hotplug framework

On 07/09/16 18:18, Boris Ostrovsky wrote: > New CPU hotplug framework was introduced recently. These patches convert Xen > CPU hotplug code to this infrastructure. Applied to for-linus-4.9, thanks. David

Re: [Xen-devel] [PATCH v2 0/2] Convert to new CPU hotplug framework

On 07/09/16 18:18, Boris Ostrovsky wrote: > New CPU hotplug framework was introduced recently. These patches convert Xen > CPU hotplug code to this infrastructure. Applied to for-linus-4.9, thanks. David

Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

On 26/08/16 22:55, KarimAllah Ahmed wrote: > Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches > from old kernel") using the INTx interrupt from Xen PCI platform device for > event channel notification would just lockup the guest during bootup. > postcore_initcall now calls

Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

On 26/08/16 22:55, KarimAllah Ahmed wrote: > Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches > from old kernel") using the INTx interrupt from Xen PCI platform device for > event channel notification would just lockup the guest during bootup. > postcore_initcall now calls

Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list

On 22/09/16 22:02, Boris Ostrovsky wrote: > On 09/22/2016 04:45 AM, Juergen Gross wrote: >> The Xen pciback driver has a list of all pci devices it is ready to >> seize. There is no check whether a to be added entry already exists. >> While this might be no problem in the common case it might

Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list

On 22/09/16 22:02, Boris Ostrovsky wrote: > On 09/22/2016 04:45 AM, Juergen Gross wrote: >> The Xen pciback driver has a list of all pci devices it is ready to >> seize. There is no check whether a to be added entry already exists. >> While this might be no problem in the common case it might

Re: [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

On 19/09/16 11:22, Vitaly Kuznetsov wrote: > David Miller writes: > >> From: Vitaly Kuznetsov >> Date: Fri, 16 Sep 2016 12:59:14 +0200 >> >>> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, >>> struct net_device *dev) >>>

Re: [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

On 19/09/16 11:22, Vitaly Kuznetsov wrote: > David Miller writes: > >> From: Vitaly Kuznetsov >> Date: Fri, 16 Sep 2016 12:59:14 +0200 >> >>> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, >>> struct net_device *dev) >>> offset = offset_in_page(skb->data); >>>

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 14/09/16 22:35, Dave Hansen wrote: > On 09/14/2016 02:01 PM, Kyle Huey wrote: >> Xen advertises the underlying support for CPUID faulting but not does pass >> through writes to the relevant MSR, nor does it virtualize it, so it does >> not actually work. For now mask off the relevant bit on

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 14/09/16 22:35, Dave Hansen wrote: > On 09/14/2016 02:01 PM, Kyle Huey wrote: >> Xen advertises the underlying support for CPUID faulting but not does pass >> through writes to the relevant MSR, nor does it virtualize it, so it does >> not actually work. For now mask off the relevant bit on

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

break; > + case MSR_PLATFORM_INFO: > + val &= ~CPUID_FAULTING_SUPPORT; > + break; > } > return val; > } Acked-by: David Vrabel <david.vra...@citrix.com> David

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

break; > + case MSR_PLATFORM_INFO: > + val &= ~CPUID_FAULTING_SUPPORT; > + break; > } > return val; > } Acked-by: David Vrabel David

[GIT PULL] xen: regression fix for 4.8-rc6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8b-rc6-tag xen: regression fix for 4.8-rc6 - - Fix SMP boot in arm guests. Thanks. David arch/arm/xen/enlighten.c | 7 +++ 1

[GIT PULL] xen: regression fix for 4.8-rc6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8b-rc6-tag xen: regression fix for 4.8-rc6 - - Fix SMP boot in arm guests. Thanks. David arch/arm/xen/enlighten.c | 7 +++ 1

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

On 09/09/16 07:14, Juergen Gross wrote: > On 08/09/16 16:10, Boris Ostrovsky wrote: >> On 09/02/2016 08:30 AM, Juergen Gross wrote: >>> Support the driver_override scheme introduced with commit 782a985d7af2 >>> ("PCI: Introduce new device binding path using pci_dev.driver_override") >>> >>> As

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

On 09/09/16 07:14, Juergen Gross wrote: > On 08/09/16 16:10, Boris Ostrovsky wrote: >> On 09/02/2016 08:30 AM, Juergen Gross wrote: >>> Support the driver_override scheme introduced with commit 782a985d7af2 >>> ("PCI: Introduce new device binding path using pci_dev.driver_override") >>> >>> As

Re: [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

th skb_copy(). > > Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> We should probably fix the backend to handle this (by grant copying a minimum amount in the linear area, but since netfront needs to work with older netback. Acked-by: David Vrabel <david.vra...@citrix.com> David

Re: [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

kb_copy(). > > Signed-off-by: Vitaly Kuznetsov We should probably fix the backend to handle this (by grant copying a minimum amount in the linear area, but since netfront needs to work with older netback. Acked-by: David Vrabel David

Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

unexpected. To solve the issue >>>>>>> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct >>>>>>> mapping >>>>>>> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary >>>>>>> CPUs

Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

id mapping. ARM and PV guests get direct >>>>>>> mapping >>>>>>> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary >>>>>>> CPUs it is a bit more trickier. Currently, we initialize IPI vectors >>&

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

On 30/08/16 16:10, Seth Forshee wrote: > On Tue, Aug 30, 2016 at 04:00:03PM +0100, David Vrabel wrote: >> On 29/08/16 16:03, Seth Forshee wrote: >>> Mounting proc in user namespace containers fails if the xenbus >>> filesystem is mounted on /proc/xen b

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

On 30/08/16 16:10, Seth Forshee wrote: > On Tue, Aug 30, 2016 at 04:00:03PM +0100, David Vrabel wrote: >> On 29/08/16 16:03, Seth Forshee wrote: >>> Mounting proc in user namespace containers fails if the xenbus >>> filesystem is mounted on /proc/xen b

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

ch mountpoints in proc but is currently > proc-internal. Export this interface to modules, then use it in > xenbus when creating /proc/xen. Acked-by: David Vrabel <david.vra...@citrix.com> This either needs to be acked by the fs maintainer or go via their tree but you don't appear to have Cc'd the relevant people or lists. David

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

ch mountpoints in proc but is currently > proc-internal. Export this interface to modules, then use it in > xenbus when creating /proc/xen. Acked-by: David Vrabel This either needs to be acked by the fs maintainer or go via their tree but you don't appear to have Cc'd the relevant people or lists. David

Re: [Xen-devel] [PATCH] xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

On 25/08/16 12:30, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 25 Aug 2016 13:23:06 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus reuse the

Re: [Xen-devel] [PATCH] xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

On 25/08/16 12:30, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 25 Aug 2016 13:23:06 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus reuse the corresponding function

Re: [Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

On 03/08/16 18:22, Boris Ostrovsky wrote: > Original version of that patch (commit a89941816726) had to be reverted > due to Xen allocating irqs in its cpu_up ops. > > The first patch moves allocations into hotplug notifiers and the second > one restores the original patch (with minor adjustments

Re: [Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

On 03/08/16 18:22, Boris Ostrovsky wrote: > Original version of that patch (commit a89941816726) had to be reverted > due to Xen allocating irqs in its cpu_up ops. > > The first patch moves allocations into hotplug notifiers and the second > one restores the original patch (with minor adjustments

Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c

On 02/08/16 07:53, Juergen Gross wrote: > There are two functions with name xen_pmu_init() in the kernel. Rename > the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in > arch/x86/xen/pmu.c > > To avoid the same problem in future rename some more functions. Applied to

Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c

On 02/08/16 07:53, Juergen Gross wrote: > There are two functions with name xen_pmu_init() in the kernel. Rename > the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in > arch/x86/xen/pmu.c > > To avoid the same problem in future rename some more functions. Applied to

Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary

On 02/08/16 08:22, Juergen Gross wrote: > The default for the Xen hypervisor is to not enable VPMU in order to > avoid security issues. In this case the Linux kernel will issue the > message "Could not initialize VPMU for cpu 0, error -95" which looks > more like an error than a normal state. > >

Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary

On 02/08/16 08:22, Juergen Gross wrote: > The default for the Xen hypervisor is to not enable VPMU in order to > avoid security issues. In this case the Linux kernel will issue the > message "Could not initialize VPMU for cpu 0, error -95" which looks > more like an error than a normal state. > >

Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t

On 29/07/16 10:06, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set'

Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t

On 29/07/16 10:06, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set'

Re: [Xen-devel] [PATCH] xenbus: don't look up transaction IDs for ordinary writes

On 15/08/16 16:02, Jan Beulich wrote: > This should really only be done for XS_TRANSACTION_END messages, or > else at least some of the xenstore-* tools don't work anymore. Applied to for-linus-4.8b, thanks. David

Re: [Xen-devel] [PATCH] xenbus: don't look up transaction IDs for ordinary writes

On 15/08/16 16:02, Jan Beulich wrote: > This should really only be done for XS_TRANSACTION_END messages, or > else at least some of the xenstore-* tools don't work anymore. Applied to for-linus-4.8b, thanks. David

[GIT PULL] xen: regression fix for 4.8-rc3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8b-rc3-tag xen: regression fix for 4.8-rc3 - - Fix a regression in the xenbus device preventing userspace tools from working.

[GIT PULL] xen: regression fix for 4.8-rc3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8b-rc3-tag xen: regression fix for 4.8-rc3 - - Fix a regression in the xenbus device preventing userspace tools from working.

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

On 22/08/16 16:42, Vitaly Kuznetsov wrote: > > I see two ways to fix the issue: > - Change the 'wire' protocol between netfront and netback to start keeping > the original SKB structure. We'll have to add a flag indicating the fact > that the particular request is a part of the original

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

On 22/08/16 16:42, Vitaly Kuznetsov wrote: > > I see two ways to fix the issue: > - Change the 'wire' protocol between netfront and netback to start keeping > the original SKB structure. We'll have to add a flag indicating the fact > that the particular request is a part of the original

Re: [Xen-devel] [PATCH 2/2] xen/events: Convert to hotplug state machine

On 15/08/16 15:46, Boris Ostrovsky wrote: > From: Sebastian Andrzej Siewior > > Install the callbacks via the state machine. [...] > +static int xen_evtchn_cpu_dead(unsigned int cpu) > +{ > + __evtchn_fifo_handle_events(cpu, true); > + return 0; > +} I'm not

Re: [Xen-devel] [PATCH 2/2] xen/events: Convert to hotplug state machine

On 15/08/16 15:46, Boris Ostrovsky wrote: > From: Sebastian Andrzej Siewior > > Install the callbacks via the state machine. [...] > +static int xen_evtchn_cpu_dead(unsigned int cpu) > +{ > + __evtchn_fifo_handle_events(cpu, true); > + return 0; > +} I'm not familiar with the new state

Re: [Xen-devel] [PATCH linux] xen: change the type of xen_vcpu_id to uint32_t

On 28/07/16 17:24, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set'

Re: [Xen-devel] [PATCH linux] xen: change the type of xen_vcpu_id to uint32_t

On 28/07/16 17:24, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set'

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On 27/07/16 04:21, Bob Liu wrote: > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount of segments. > * max_ring_page_order: Maximum order of pages to be used for

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On 27/07/16 04:21, Bob Liu wrote: > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount of segments. > * max_ring_page_order: Maximum order of pages to be used for

[GIT PULL] xen: features and fixes for 4.8-rc0

): xen/PMU: Log VPMU initialization error at lower level David Vrabel (1): xen/evtchn: add IOCTL_EVTCHN_RESTRICT Jan Beulich (11): xen-pciback: drop unused function parameter of read_dev_bar() xen-pciback: drop rom_init() xen-pciback: fold read_dev_bar() into its now

[GIT PULL] xen: features and fixes for 4.8-rc0

): xen/PMU: Log VPMU initialization error at lower level David Vrabel (1): xen/evtchn: add IOCTL_EVTCHN_RESTRICT Jan Beulich (11): xen-pciback: drop unused function parameter of read_dev_bar() xen-pciback: drop rom_init() xen-pciback: fold read_dev_bar() into its now

Re: [Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

On 26/07/16 13:15, Juergen Gross wrote: > pv_time_ops might be overwritten with xen_time_ops after the > steal_clock operation has been initialized already. To prevent calling > a now uninitialized function pointer add the steal_clock static > initialization to xen_time_ops. Applied to

Re: [Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

On 26/07/16 13:15, Juergen Gross wrote: > pv_time_ops might be overwritten with xen_time_ops after the > steal_clock operation has been initialized already. To prevent calling > a now uninitialized function pointer add the steal_clock static > initialization to xen_time_ops. Applied to

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 26/07/16 13:30, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 26/07/16 13:30, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 25/07/16 15:01, Julien Grall wrote: > Hello, > > On 25/07/16 14:39, Vitaly Kuznetsov wrote: >> Julien Grall <julien.gr...@arm.com> writes: >> >>> Hi David, >>> >>> On 25/07/16 13:38, David Vrabel wrote: >>>> On 30/06/16 16:56,

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 25/07/16 15:01, Julien Grall wrote: > Hello, > > On 25/07/16 14:39, Vitaly Kuznetsov wrote: >> Julien Grall writes: >> >>> Hi David, >>> >>> On 25/07/16 13:38, David Vrabel wrote: >>>> On 30/06/16 16:56, Vitaly Kuznetsov wrote:

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 25/07/16 14:17, Julien Grall wrote: > Hi David, > > On 25/07/16 13:38, David Vrabel wrote: >> On 30/06/16 16:56, Vitaly Kuznetsov wrote: >>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In >>> particular, when we crash on a secon

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 25/07/16 14:17, Julien Grall wrote: > Hi David, > > On 25/07/16 13:38, David Vrabel wrote: >> On 30/06/16 16:56, Vitaly Kuznetsov wrote: >>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In >>> particular, when we crash on a secon

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 30/06/16 16:56, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 30/06/16 16:56, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

ve _PAGE_PRESENT set. > > It does seem fragile that Xen is doing it this way, but I guess it works. Xen PV guests never plays games with non-present PTEs so, for the series, wrt Xen: Acked-by: David Vrabel <david.vra...@citrix.com> FWIW, present PTEs have a hardware-specified meaning where-as non-present PTEs do not, so I'm not sure I'd view Xen PV guests making this distinct as "fragile". David

Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

ve _PAGE_PRESENT set. > > It does seem fragile that Xen is doing it this way, but I guess it works. Xen PV guests never plays games with non-present PTEs so, for the series, wrt Xen: Acked-by: David Vrabel FWIW, present PTEs have a hardware-specified meaning where-as non-present PTEs do not, so I'm not sure I'd view Xen PV guests making this distinct as "fragile". David

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

being called later. Prioritising the in-kernel kexec image over the hypervisor one seems sensible behaviour to me. Reviewed-by: David Vrabel <david.vra...@citrix.com> David

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

being called later. Prioritising the in-kernel kexec image over the hypervisor one seems sensible behaviour to me. Reviewed-by: David Vrabel David

Re: [Xen-devel] [PATCH] xen_pvscsi: reclaim the ring request when mapping data failed

On 11/07/16 10:33, Juergen Gross wrote: > On 11/07/16 04:51, Bin Wu wrote: >> During scsi command queueing, if mapping data fails, we need to >> reclaim the failed request. Otherwise, the garbage request will >> be pushed into the ring for the backend to work. > > Well spotted. There is another

Re: [Xen-devel] [PATCH] xen_pvscsi: reclaim the ring request when mapping data failed

On 11/07/16 10:33, Juergen Gross wrote: > On 11/07/16 04:51, Bin Wu wrote: >> During scsi command queueing, if mapping data fails, we need to >> reclaim the failed request. Otherwise, the garbage request will >> be pushed into the ring for the backend to work. > > Well spotted. There is another

Re: [Xen-devel] [PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

On 28/06/16 19:06, David Vrabel wrote: > simple_fill_super() will add symlinks if an entry has mode & S_IFLNK. > The target is provided in the new "link" field. Can I get an ack for this, please? So it can go into 4.8 via the Xen tree. David > > Signed-off-b

Re: [Xen-devel] [PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

On 28/06/16 19:06, David Vrabel wrote: > simple_fill_super() will add symlinks if an entry has mode & S_IFLNK. > The target is provided in the new "link" field. Can I get an ack for this, please? So it can go into 4.8 via the Xen tree. David > > Signed-off-by

  1   2   3   4   5   6   7   8   9   10   >