[tip:efi/core] efi/bgrt: Use efi_mem_type()

Commit-ID: 6de47a5e371f75f80544986e6c9636211a2ae8af Gitweb: http://git.kernel.org/tip/6de47a5e371f75f80544986e6c9636211a2ae8af Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Fri, 25 Aug 2017 16:50:19 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat, 26 Au

[tip:efi/core] efi/bgrt: Use efi_mem_type()

Commit-ID: 6de47a5e371f75f80544986e6c9636211a2ae8af Gitweb: http://git.kernel.org/tip/6de47a5e371f75f80544986e6c9636211a2ae8af Author: Jan Beulich AuthorDate: Fri, 25 Aug 2017 16:50:19 +0100 Committer: Ingo Molnar CommitDate: Sat, 26 Aug 2017 09:20:33 +0200 efi/bgrt: Use efi_mem_type

[PATCH] x86: use KERN_CONT in dump_pagetable()

The lack of newlines in preceding format strings is a clear indication that these were meant to be continuations of one another, and indeed output ends up quite a bit more compact (and readable) that way. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- arch/x86/mm/fault.c

[PATCH] x86: use KERN_CONT in dump_pagetable()

The lack of newlines in preceding format strings is a clear indication that these were meant to be continuations of one another, and indeed output ends up quite a bit more compact (and readable) that way. Signed-off-by: Jan Beulich --- arch/x86/mm/fault.c | 14 +++--- 1 file changed

Re: [Xen-devel] [PATCH v2] xen/balloon: don't online new memory initially

>>> On 05.07.17 at 17:38, wrote: > @@ -94,22 +103,15 @@ static struct notifier_block xenstore_notifier = { > .notifier_call = balloon_init_watcher, > }; > > -static int __init balloon_init(void) > +void __init xen_balloon_init(void) > { > - if (!xen_domain()) > -

Re: [Xen-devel] [PATCH v2] xen/balloon: don't online new memory initially

>>> On 05.07.17 at 17:38, wrote: > @@ -94,22 +103,15 @@ static struct notifier_block xenstore_notifier = { > .notifier_call = balloon_init_watcher, > }; > > -static int __init balloon_init(void) > +void __init xen_balloon_init(void) > { > - if (!xen_domain()) > - return

Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device

>>> On 05.07.17 at 14:37, <vincent.leg...@gandi.net> wrote: > On Wed, Jul 05, 2017 at 02:17:24AM -0600, Jan Beulich wrote : >> >>> On 05.07.17 at 10:08, <vincent.leg...@gandi.net> wrote: >> > Without the patch, blkif_release and xlvbd_re

Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device

>>> On 05.07.17 at 14:37, wrote: > On Wed, Jul 05, 2017 at 02:17:24AM -0600, Jan Beulich wrote : >> >>> On 05.07.17 at 10:08, wrote: >> > Without the patch, blkif_release and xlvbd_release_gendisk are never >> > called, and no call to blk_unregis

Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device

>>> On 05.07.17 at 10:08, wrote: > Without the patch, blkif_release and xlvbd_release_gendisk are never > called, and no call to blk_unregister_queue is made. But isn't that what needs to be fixed then? The device should be removed once its last user goes away (which

Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device

>>> On 05.07.17 at 10:08, wrote: > Without the patch, blkif_release and xlvbd_release_gendisk are never > called, and no call to blk_unregister_queue is made. But isn't that what needs to be fixed then? The device should be removed once its last user goes away (which would be at the time the

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

>>> On 03.07.17 at 17:40, wrote: > --- a/drivers/xen/xen-balloon.c > +++ b/drivers/xen/xen-balloon.c > @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch, > { > unsigned long long new_target; > int err; > + static bool watch_fired; > +

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

>>> On 03.07.17 at 17:40, wrote: > --- a/drivers/xen/xen-balloon.c > +++ b/drivers/xen/xen-balloon.c > @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch, > { > unsigned long long new_target; > int err; > + static bool watch_fired; > + static unsigned long

Re: [Xen-devel] [PATCH v1] xen: fix HYPERVISOR_dm_op() prototype

>>> On 05.06.17 at 10:41, wrote: > --- a/arch/x86/include/asm/xen/hypercall.h > +++ b/arch/x86/include/asm/xen/hypercall.h > @@ -49,6 +49,7 @@ > #include > #include > #include > +#include Why? > @@ -474,7 +475,7 @@ HYPERVISOR_xenpmu_op(unsigned int op, void

Re: [Xen-devel] [PATCH v1] xen: fix HYPERVISOR_dm_op() prototype

>>> On 05.06.17 at 10:41, wrote: > --- a/arch/x86/include/asm/xen/hypercall.h > +++ b/arch/x86/include/asm/xen/hypercall.h > @@ -49,6 +49,7 @@ > #include > #include > #include > +#include Why? > @@ -474,7 +475,7 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg) > > static inline int

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

>>> On 22.05.17 at 17:28, wrote: > On 22/05/17 17:23, Konrad Rzeszutek Wilk wrote: >> On Mon, May 22, 2017 at 10:57:00AM +0200, Juergen Gross wrote: >>> --- a/Documentation/ABI/testing/sysfs-hypervisor >>> +++ b/Documentation/ABI/testing/sysfs-hypervisor >>> @@ -19,6 +19,19 @@

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

>>> On 22.05.17 at 17:28, wrote: > On 22/05/17 17:23, Konrad Rzeszutek Wilk wrote: >> On Mon, May 22, 2017 at 10:57:00AM +0200, Juergen Gross wrote: >>> --- a/Documentation/ABI/testing/sysfs-hypervisor >>> +++ b/Documentation/ABI/testing/sysfs-hypervisor >>> @@ -19,6 +19,19 @@ Contact:

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

>>> On 22.05.17 at 10:57, wrote: > --- a/include/xen/xen.h > +++ b/include/xen/xen.h > @@ -9,8 +9,10 @@ enum xen_domain_type { > > #ifdef CONFIG_XEN > extern enum xen_domain_type xen_domain_type; > +extern char *xen_guest_type; const char * ? Jan

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

>>> On 22.05.17 at 10:57, wrote: > --- a/include/xen/xen.h > +++ b/include/xen/xen.h > @@ -9,8 +9,10 @@ enum xen_domain_type { > > #ifdef CONFIG_XEN > extern enum xen_domain_type xen_domain_type; > +extern char *xen_guest_type; const char * ? Jan

Re: [Xen-devel] [PATCH] xen: adjust early dom0 p2m handling to xen hypervisor behavior

s bits not being zero in this special case. > > Signed-off-by: Juergen Gross <jgr...@suse.com> Reviewed-by: Jan Beulich <jbeul...@suse.com> Perhaps worth Cc-ing stable@ ? Jan

Re: [Xen-devel] [PATCH] xen: adjust early dom0 p2m handling to xen hypervisor behavior

n this special case. > > Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Perhaps worth Cc-ing stable@ ? Jan

Re: [RFC] Increase Minimal GNU Make version for Linux Kernel from 3.80 to 3.81

s not just the kbuild change that broke it, but as you say, > new make features tend creep into random Makefiles. So I'm fine > adjusting the documentation to match reality. > > Adding Jan Beulich to Cc, who to fix these cases in the past. Thanks for asking. As I don't recall having r

Re: [RFC] Increase Minimal GNU Make version for Linux Kernel from 3.80 to 3.81

hange that broke it, but as you say, > new make features tend creep into random Makefiles. So I'm fine > adjusting the documentation to match reality. > > Adding Jan Beulich to Cc, who to fix these cases in the past. Thanks for asking. As I don't recall having run into the specific pr

Re: [Xen-devel] xen_exit_mmap() questions

>>> On 27.04.17 at 02:55, wrote: > The point of CR3 loading here, I believe, is to make sure the hypervisor > knows that the (v)CPU is no longer using the the mm's cr3 (we are > loading swapper_pgdir here). Correct, or else there would still be a non-zero refcount

Re: [Xen-devel] xen_exit_mmap() questions

>>> On 27.04.17 at 02:55, wrote: > The point of CR3 loading here, I believe, is to make sure the hypervisor > knows that the (v)CPU is no longer using the the mm's cr3 (we are > loading swapper_pgdir here). Correct, or else there would still be a non-zero refcount for the page tables hanging

Re: [Xen-devel] [PATCH] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

>>> On 30.03.17 at 16:18, wrote: > @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct > *vma, > return -EINVAL; > } > EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range); > + > +#ifdef CONFIG_KEXEC_CORE > +phys_addr_t paddr_vmcoreinfo_note(void) > +{ >

Re: [Xen-devel] [PATCH] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

>>> On 30.03.17 at 16:18, wrote: > @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct > *vma, > return -EINVAL; > } > EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range); > + > +#ifdef CONFIG_KEXEC_CORE > +phys_addr_t paddr_vmcoreinfo_note(void) > +{ > + if

Re: [Xen-devel] maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

>>> On 28.03.17 at 16:27, wrote: > Which leaves hvmloader's special pages (and possibly memory under > 0xA which may get reserved). Can we pass this info to guests via > xenstore? I'm perhaps the wrong one to ask regarding xenstore, but for in-guest communication

Re: [Xen-devel] maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

>>> On 28.03.17 at 16:27, wrote: > Which leaves hvmloader's special pages (and possibly memory under > 0xA which may get reserved). Can we pass this info to guests via > xenstore? I'm perhaps the wrong one to ask regarding xenstore, but for in-guest communication this seems an at least

Re: [Xen-devel] maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

>>> On 28.03.17 at 03:57, wrote: > I think there is indeed a disconnect between target memory (provided by > the toolstack) and current memory (i.e actual pages available to the guest). > > For example > > [0.00] BIOS-e820: [mem

Re: [Xen-devel] maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

>>> On 28.03.17 at 03:57, wrote: > I think there is indeed a disconnect between target memory (provided by > the toolstack) and current memory (i.e actual pages available to the guest). > > For example > > [0.00] BIOS-e820: [mem 0x0009e000-0x0009] > reserved > [

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 14:56, <jgr...@suse.com> wrote: > On 23/03/17 14:37, Jan Beulich wrote: >>>>> On 23.03.17 at 13:52, <jgr...@suse.com> wrote: >>> Connecting to the backend isn't working reliably in xen-fbfront: in >>> case Xenbu

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 14:56, wrote: > On 23/03/17 14:37, Jan Beulich wrote: >>>>> On 23.03.17 at 13:52, wrote: >>> Connecting to the backend isn't working reliably in xen-fbfront: in >>> case XenbusStateInitWait of the backend has been missed the b

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 13:52, wrote: > Connecting to the backend isn't working reliably in xen-fbfront: in > case XenbusStateInitWait of the backend has been missed the backend > transition to XenbusStateConnected will trigger the connected state > only without doing the actions

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 13:52, wrote: > Connecting to the backend isn't working reliably in xen-fbfront: in > case XenbusStateInitWait of the backend has been missed the backend > transition to XenbusStateConnected will trigger the connected state > only without doing the actions required when the

[tip:x86/asm] x86/entry/64: Relax pvops stub clobber specifications

Commit-ID: 2140a9942b84dd4bf559dd1215b8f43c36ece5b5 Gitweb: http://git.kernel.org/tip/2140a9942b84dd4bf559dd1215b8f43c36ece5b5 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Fri, 3 Feb 2017 02:03:25 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 1 Mar 2

[tip:x86/asm] x86/entry/64: Relax pvops stub clobber specifications

Commit-ID: 2140a9942b84dd4bf559dd1215b8f43c36ece5b5 Gitweb: http://git.kernel.org/tip/2140a9942b84dd4bf559dd1215b8f43c36ece5b5 Author: Jan Beulich AuthorDate: Fri, 3 Feb 2017 02:03:25 -0700 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017 10:16:35 +0100 x86/entry/64: Relax pvops

[tip:x86/asm] x86/entry/32: Relax a pvops stub clobber specification

Commit-ID: fdbd518adfaf2c10903250dffe70c61ed90b7dd7 Gitweb: http://git.kernel.org/tip/fdbd518adfaf2c10903250dffe70c61ed90b7dd7 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Fri, 3 Feb 2017 01:58:03 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 1 Mar 2

[tip:x86/asm] x86/entry/32: Relax a pvops stub clobber specification

Commit-ID: fdbd518adfaf2c10903250dffe70c61ed90b7dd7 Gitweb: http://git.kernel.org/tip/fdbd518adfaf2c10903250dffe70c61ed90b7dd7 Author: Jan Beulich AuthorDate: Fri, 3 Feb 2017 01:58:03 -0700 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017 10:16:30 +0100 x86/entry/32: Relax a pvops

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

>>> On 09.02.17 at 16:56, wrote: > On 09/02/17 15:50, Boris Ostrovsky wrote: >> >> >> On 02/09/2017 09:27 AM, Paul Durrant wrote: -Original Message- From: Paul Durrant [mailto:paul.durr...@citrix.com] Sent: 09 February 2017 14:18 To:

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

>>> On 09.02.17 at 16:56, wrote: > On 09/02/17 15:50, Boris Ostrovsky wrote: >> >> >> On 02/09/2017 09:27 AM, Paul Durrant wrote: -Original Message- From: Paul Durrant [mailto:paul.durr...@citrix.com] Sent: 09 February 2017 14:18 To: xen-de...@lists.xenproject.org;

Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT

>>> On 09.02.17 at 15:17, wrote: > @@ -666,6 +680,20 @@ static long privcmd_ioctl_dm_op(void __user *udata) > return rc; > } > > +static long privcmd_ioctl_restrict(struct file *file, void __user *udata) > +{ > + struct privcmd_data *data =

Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT

>>> On 09.02.17 at 15:17, wrote: > @@ -666,6 +680,20 @@ static long privcmd_ioctl_dm_op(void __user *udata) > return rc; > } > > +static long privcmd_ioctl_restrict(struct file *file, void __user *udata) > +{ > + struct privcmd_data *data = file->private_data; > + domid_t dom; >

Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

>>> On 09.02.17 at 15:17, wrote: > The code goes so far as to set the default return code to -ENOSYS but > then overrides this to -EINVAL in the switch() statement's default > case. If you already change this, isn't -ENOTTY the traditional way of indicating unsupported

Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

>>> On 09.02.17 at 15:17, wrote: > The code goes so far as to set the default return code to -ENOSYS but > then overrides this to -EINVAL in the switch() statement's default > case. If you already change this, isn't -ENOTTY the traditional way of indicating unsupported ioctls? Jan

[PATCH] x86-64: relax pvops stub clobber specifications

an instruction) also allows for this to be true. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- arch/x86/entry/entry_64.S | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) --- 4.10-rc6/arch/x86/entry/entry_64.S +++ 4.10-rc6-x86_64-relax-clobbers/arch/x86/entry/entr

[PATCH] x86-64: relax pvops stub clobber specifications

an instruction) also allows for this to be true. Signed-off-by: Jan Beulich --- arch/x86/entry/entry_64.S | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) --- 4.10-rc6/arch/x86/entry/entry_64.S +++ 4.10-rc6-x86_64-relax-clobbers/arch/x86/entry/entry_64.S @@ -212,7 +212,7

[PATCH] ix86: relax a pvops stub clobber specification

The code at .Lrestore_nocheck does not make any assumptions on register values, so all registers can be clobbered on code paths leading there. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- arch/x86/entry/entry_32.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 4.10-rc

[PATCH] ix86: relax a pvops stub clobber specification

The code at .Lrestore_nocheck does not make any assumptions on register values, so all registers can be clobbered on code paths leading there. Signed-off-by: Jan Beulich --- arch/x86/entry/entry_32.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 4.10-rc6/arch/x86/entry/entry_32

[PATCH v2 RESEND] xen/manage: correct return value check on xenbus_scanf()

A negative return value indicates an error; in fact the function at present won't ever return zero. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- v2: For consistency with other code don't consider zero an error (utilizing that

[PATCH v2 RESEND] xen/manage: correct return value check on xenbus_scanf()

A negative return value indicates an error; in fact the function at present won't ever return zero. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- v2: For consistency with other code don't consider zero an error (utilizing that xenbus_scanf() at present won't return zero

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

>>> On 15.12.16 at 17:46, wrote: > On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >> with today's kernel the system isn't coming up when booted as Xen dom0: > > Remind me again pls, is dom0 even supposed to load microcode? Isn't the > hypervisor supposed to apply

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

>>> On 15.12.16 at 17:46, wrote: > On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >> with today's kernel the system isn't coming up when booted as Xen dom0: > > Remind me again pls, is dom0 even supposed to load microcode? Isn't the > hypervisor supposed to apply microcode? Yes,

Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

>>> On 05.12.16 at 22:32, wrote: > static inline void sync_core(void) > { > - int tmp; > - > -#ifdef CONFIG_X86_32 > /* > - * Do a CPUID if available, otherwise do a jump. The jump > - * can conveniently enough be the jump around CPUID. > + * There are

Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

>>> On 05.12.16 at 22:32, wrote: > static inline void sync_core(void) > { > - int tmp; > - > -#ifdef CONFIG_X86_32 > /* > - * Do a CPUID if available, otherwise do a jump. The jump > - * can conveniently enough be the jump around CPUID. > + * There are quite a few ways

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

>>> On 29.11.16 at 12:19, <jgr...@suse.com> wrote: > On 29/11/16 12:14, Jan Beulich wrote: >>>>> On 29.11.16 at 11:50, <jgr...@suse.com> wrote: >>> --- a/drivers/scsi/xen-scsifront.c >>> +++ b/drivers/scsi/xen-scsifront.c >>> @@

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

>>> On 29.11.16 at 12:19, 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_req

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

>>> 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 *info) > > ring_req = RING_GET_REQUEST(&(info->ring),

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

>>> 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 *info) > > ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt); > > -

[PATCH] x86: add UMIP support

This is a small aid to security, hiding in particular the kernel address information otherwise available through SGDT/SIDT. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- Main question here is whether to limit this to 64-bit (or at least !CONFIG_VM86) for the time being, or to d

[PATCH] x86: add UMIP support

This is a small aid to security, hiding in particular the kernel address information otherwise available through SGDT/SIDT. Signed-off-by: Jan Beulich --- Main question here is whether to limit this to 64-bit (or at least !CONFIG_VM86) for the time being, or to disable it while running VM86 mode

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 12:07, <jgr...@suse.com> wrote: > On 15/11/16 11:44, Jan Beulich wrote: >>>>> On 15.11.16 at 10:55, <jgr...@suse.com> wrote: >>> On 15/11/16 10:45, Jan Beulich wrote: >>>>>>> On 15.11.16 at 09:42, <jgr.

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 12:07, wrote: > On 15/11/16 11:44, Jan Beulich wrote: >>>>> On 15.11.16 at 10:55, wrote: >>> On 15/11/16 10:45, Jan Beulich wrote: >>>>>>> On 15.11.16 at 09:42, wrote: >>>>> For a fully dynamical solu

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 10:55, <jgr...@suse.com> wrote: > On 15/11/16 10:45, Jan Beulich wrote: >>>>> On 15.11.16 at 09:42, <jgr...@suse.com> wrote: >>> For a fully dynamical solution we'd need a way to get a partial >>> E820 map from the hy

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 10:55, wrote: > On 15/11/16 10:45, Jan Beulich wrote: >>>>> On 15.11.16 at 09:42, wrote: >>> For a fully dynamical solution we'd need a way to get a partial >>> E820 map from the hypervisor (e.g. first 128 entries) in order

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 09:42, <jgr...@suse.com> wrote: > On 15/11/16 09:01, Jan Beulich wrote: >>>>> On 15.11.16 at 08:36, <jgr...@suse.com> wrote: >>> On 15/11/16 08:15, Jan Beulich wrote: >>>>>>> On 15.11.16 at 07:33, <j

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 09:42, wrote: > On 15/11/16 09:01, Jan Beulich wrote: >>>>> On 15.11.16 at 08:36, wrote: >>> On 15/11/16 08:15, Jan Beulich wrote: >>>>>>> On 15.11.16 at 07:33, wrote: >>>>> In case I'm right the Xen h

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 08:36, <jgr...@suse.com> wrote: > On 15/11/16 08:15, Jan Beulich wrote: >>>>> On 15.11.16 at 07:33, <jgr...@suse.com> wrote: >>> On 15/11/16 01:11, Alex Thorlton wrote: >>>> Hey everyone, >>>> >>>

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 08:36, wrote: > On 15/11/16 08:15, Jan Beulich wrote: >>>>> On 15.11.16 at 07:33, wrote: >>> On 15/11/16 01:11, Alex Thorlton wrote: >>>> Hey everyone, >>>> >>>> We're having problems with large systems h

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 07:33, wrote: > On 15/11/16 01:11, Alex Thorlton wrote: >> Hey everyone, >> >> We're having problems with large systems hitting a BUG in >> xen_memory_setup, due to extra e820 entries created in the >> XENMEM_machine_memory_map callback. The change in the

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

>>> On 15.11.16 at 07:33, wrote: > On 15/11/16 01:11, Alex Thorlton wrote: >> Hey everyone, >> >> We're having problems with large systems hitting a BUG in >> xen_memory_setup, due to extra e820 entries created in the >> XENMEM_machine_memory_map callback. The change in the patch gets things >>

[PATCH v2] xen/manage: correct return value check on xenbus_scanf()

A negative return value indicates an error; in fact the function at present won't ever return zero. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- v2: For consistency with other code don't consider zero an error (utilizing that xenbus_scanf() at present won't return zero).

[PATCH v2] xen/manage: correct return value check on xenbus_scanf()

A negative return value indicates an error; in fact the function at present won't ever return zero. Signed-off-by: Jan Beulich --- v2: For consistency with other code don't consider zero an error (utilizing that xenbus_scanf() at present won't return zero). Adjust commit message

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

>>> On 31.10.16 at 09:28, wrote: >> > ref = gnttab_claim_grant_reference(>gref_rx_head); >> > -BUG_ON((signed short)ref < 0); >> > +WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref)); > >> You really need to cast to plain (or

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

>>> On 31.10.16 at 09:28, wrote: >> > ref = gnttab_claim_grant_reference(>gref_rx_head); >> > -BUG_ON((signed short)ref < 0); >> > +WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref)); > >> You really need to cast to plain (or signed) long here -

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

>>> On 31.10.16 at 06:38, wrote: > --- a/drivers/net/xen-netfront.c > +++ b/drivers/net/xen-netfront.c > @@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue > *queue) > queue->rx_skbs[id] = skb; > > ref =

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

>>> On 31.10.16 at 06:38, wrote: > --- a/drivers/net/xen-netfront.c > +++ b/drivers/net/xen-netfront.c > @@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue > *queue) > queue->rx_skbs[id] = skb; > > ref =

[tip:x86/urgent] x86/build: Fix build with older GCC versions

Commit-ID: a2209b742e6cf978b85d4f31a25a269c3d3b062b Gitweb: http://git.kernel.org/tip/a2209b742e6cf978b85d4f31a25a269c3d3b062b Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 24 Oct 2016 09:00:12 -0600 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 25 Oc

[tip:x86/urgent] x86/build: Fix build with older GCC versions

Commit-ID: a2209b742e6cf978b85d4f31a25a269c3d3b062b Gitweb: http://git.kernel.org/tip/a2209b742e6cf978b85d4f31a25a269c3d3b062b Author: Jan Beulich AuthorDate: Mon, 24 Oct 2016 09:00:12 -0600 Committer: Ingo Molnar CommitDate: Tue, 25 Oct 2016 11:44:25 +0200 x86/build: Fix build

[PATCH RESEND] xenbus: check return value of xenbus_scanf()

Don't ignore errors here: Set backend state to unknown when unsuccessful. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- drivers/xen/xenbus/xenbus_probe_frontend.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- 4.9-rc2/drivers/xen/xenbus/xenbus_probe_frontend.c +++ 4

[PATCH RESEND] xenbus: check return value of xenbus_scanf()

Don't ignore errors here: Set backend state to unknown when unsuccessful. Signed-off-by: Jan Beulich --- drivers/xen/xenbus/xenbus_probe_frontend.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- 4.9-rc2/drivers/xen/xenbus/xenbus_probe_frontend.c +++ 4.9-rc2-xenbus-xenbus_scanf

[PATCH v2 RESEND] xenbus: prefer list_for_each()

This is more efficient than list_for_each_safe() when list modification is accompanied by breaking out of the loop. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- v2: Avoid commit message to continue from subject. --- driver

[PATCH v2 RESEND] xenbus: prefer list_for_each()

This is more efficient than list_for_each_safe() when list modification is accompanied by breaking out of the loop. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- v2: Avoid commit message to continue from subject. --- drivers/xen/xenbus/xenbus_dev_frontend.c |4 ++-- 1 file

[PATCH] x86: fix build with older gcc

Older gcc (observed with 4.1.x) doesn't support -Wno-override-init and also doesn't ignore unknown -Wno-* options. Fixes: 5e44258d16 "x86/build: Reduce the W=1 warnings noise when compiling x86 syscall tables" Signed-off-by: Jan Beulich <jbeul...@suse.com> Cc: Valdis Kletniek

[PATCH] x86: fix build with older gcc

Older gcc (observed with 4.1.x) doesn't support -Wno-override-init and also doesn't ignore unknown -Wno-* options. Fixes: 5e44258d16 "x86/build: Reduce the W=1 warnings noise when compiling x86 syscall tables" Signed-off-by: Jan Beulich Cc: Valdis Kletnieks --- arch/x86/entry/Makef

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 13.10.16 at 17:46, <haozhong.zh...@intel.com> wrote: > On 10/13/16 03:08 -0600, Jan Beulich wrote: >>>>> On 13.10.16 at 10:53, <haozhong.zh...@intel.com> wrote: >>> On 10/13/16 02:34 -0600, Jan Beulich wrote: >>>>>>> On 1

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 13.10.16 at 17:46, wrote: > On 10/13/16 03:08 -0600, Jan Beulich wrote: >>>>> On 13.10.16 at 10:53, wrote: >>> On 10/13/16 02:34 -0600, Jan Beulich wrote: >>>>>>> On 12.10.16 at 18:19, wrote: >>>>> On Wed, Oct

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 13.10.16 at 17:40, <dan.j.willi...@intel.com> wrote: > On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich <jbeul...@suse.com> wrote: > [..] >>> I think we can do the similar for Xen, like to lay another pseudo >>> device on /dev/pmem and do the

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 13.10.16 at 17:40, wrote: > On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: > [..] >>> I think we can do the similar for Xen, like to lay another pseudo >>> device on /dev/pmem and do the reservation, like 2. in my previous >>> reply. >

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 13.10.16 at 10:53, <haozhong.zh...@intel.com> wrote: > On 10/13/16 02:34 -0600, Jan Beulich wrote: >>>>> On 12.10.16 at 18:19, <dan.j.willi...@intel.com> wrote: >>> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich <jbeul...@suse.com

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 13.10.16 at 10:53, wrote: > On 10/13/16 02:34 -0600, Jan Beulich wrote: >>>>> On 12.10.16 at 18:19, wrote: >>> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: >>>>>>> On 12.10.16 at 17:42, wrote: >>>>> On Wed,

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 18:19, <dan.j.willi...@intel.com> wrote: > On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>> On 12.10.16 at 17:42, <dan.j.willi...@intel.com> wrote: >>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulic

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 18:19, wrote: > On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: >>>>> On 12.10.16 at 17:42, wrote: >>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: >>>>>>> On 12.10.16 at 16:58, wrote: >>>>>

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 17:42, <dan.j.willi...@intel.com> wrote: > On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>> On 12.10.16 at 16:58, <haozhong.zh...@intel.com> wrote: >>> On 10/12/16 05:32 -0600, Jan Beu

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 17:42, wrote: > On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: >>>>> On 12.10.16 at 16:58, wrote: >>> On 10/12/16 05:32 -0600, Jan Beulich wrote: >>>>>>> On 12.10.16 at 12:33,

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 16:58, <haozhong.zh...@intel.com> wrote: > On 10/12/16 05:32 -0600, Jan Beulich wrote: >>>>> On 12.10.16 at 12:33, <haozhong.zh...@intel.com> wrote: >>&

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 16:58, wrote: > On 10/12/16 05:32 -0600, Jan Beulich wrote: >>>>> On 12.10.16 at 12:33, wrote: >>> The layout is shown as the following diagram. >>> >>> +---+---+---+--+--+ >

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > > +---+---+---+--+--+ > | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | > | by kernel| Table | Block | for Xen |

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > > +---+---+---+--+--+ > | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | > | by kernel| Table | Block | for Xen | | >

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 11.10.16 at 17:53, <dan.j.willi...@intel.com> wrote: > On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>> Andrew Cooper <andrew.coop...@citrix.com> 10/10/16 6:44 PM >>> >>>On 10/10/16 01:35, Haozh

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

>>> On 11.10.16 at 17:53, wrote: > On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich wrote: >>>>> Andrew Cooper 10/10/16 6:44 PM >>> >>>On 10/10/16 01:35, Haozhong Zhang wrote: >>>> Xen hypervisor needs assistance from Dom0 Linux kernel for f

<    1   2   3   4   5   6   7   8   9   10   >