Re: [Xen-devel] [PATCH 2/4] xen/pciback: Save the number of MSI-X entries to be copied later.

>>> On 11.02.16 at 22:10, wrote: > c/s 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 > "xen/pciback: Save xen_pci_op commands before processing it" > would copyback the processed values - which was great. > > However it missed the case that xen_pcibk_enable_msix - when >

[Xen-devel] [PATCH v2 2/2] xen: credit1: avoid boosting vCPUs being "just" migrated

Moving a vCPU to a different pCPU means offlining it and then waking it up, on the new pCPU. Credit1 grants BOOST priority to vCPUs that wakes up, with the aim of improving I/O latency. The net effect of this all is that vCPUs get boosted when migrating, which shouldn't happen. For instance, this

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

>>> On 11.02.16 at 20:25, wrote: > CentOS 7 gets into trouble when compiling Xen citing: > > flushtlb.c: Assembler messages: > flushtlb.c:149: Error: value of 256 too large for field of 1 bytes at 1 > > The line number is wrong, and the error message not helpful.

Re: [Xen-devel] [PATCH] vm_event: Remove xc_mem_access_enable_emulate() and friends

>>> On 12.02.16 at 10:04, wrote: > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -390,8 +390,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t); > #define XENMEM_access_op21 > #define XENMEM_access_op_set_access

[Xen-devel] [PATCH 0/2] xen: sched: Credit1 shouldn't boost vcpus being migrated.

Hi again, Here it comes v2, redone following Jan's suggestion, which allowed to get rid of patch 2, and do everything in sched_credit.c. So, in summary, because of the fact that vcpu_migrate() forces the vcpus into a sleep+wakeup cycle, vcpus being migrated to a new pcpu, were also being granted

[Xen-devel] Anyone know where the official qemu(1) man pages are hosted?

I noticed that the qemu(1) links in http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html (and probably other docs) are broken. They go to http://man.he.net/man1/qemu, which does not exist any more Lars ___ Xen-devel mailing list

[Xen-devel] [PATCH v2 1/2] xen: credit1: trace vCPU boost/unboost

Add tracepoints and a performance counter for boosting and unboosting in Credit1. Note that they (the trace points) do not cover the case of the idle vCPU being boosted to run a tasklet, as there already is TRC_CSCHED_SCHED_TASKLET for that. Signed-off-by: Dario Faggioli

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

On 12/02/16 08:13, Jan Beulich wrote: On 11.02.16 at 20:41, wrote: >> On 11/02/16 19:25, Andrew Cooper wrote: >>> --- a/xen/arch/x86/flushtlb.c >>> +++ b/xen/arch/x86/flushtlb.c >>> @@ -141,10 +141,10 @@ void flush_area_local(const void *va, unsigned int >>>

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

>>> On 12.02.16 at 10:51, wrote: > On 12/02/16 08:23, Jan Beulich wrote: > On 11.02.16 at 20:25, wrote: >>> CentOS 7 gets into trouble when compiling Xen citing: >>> >>> flushtlb.c: Assembler messages: >>> flushtlb.c:149: Error: value

Re: [Xen-devel] [PATCH] vm_event: Remove xc_mem_access_enable_emulate() and friends

On 02/12/2016 11:10 AM, Jan Beulich wrote: On 12.02.16 at 10:04, wrote: >> --- a/xen/include/public/memory.h >> +++ b/xen/include/public/memory.h >> @@ -390,8 +390,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t); >> #define XENMEM_access_op21

Re: [Xen-devel] [PATCH] xen/common: Uniformally use __ varients for attribute names

>>> On 11.02.16 at 20:51, wrote: > Otherwise, debug code such as "void __attribute__((noreturn)) foobar()" fails > to compile when the noreturn itself gets expanded, resulting in > __attribute__((__attribute__((noreturn. Well, why would the debugging code not use

Re: [Xen-devel] [PATCH v2 2/2] xen: credit1: avoid boosting vCPUs being "just" migrated

>>> On 12.02.16 at 10:37, wrote: > @@ -787,6 +788,16 @@ _csched_cpu_pick(const struct scheduler *ops, struct > vcpu *vc, bool_t commit) > static int > csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc) > { > +struct csched_vcpu *svc = CSCHED_VCPU(vc);

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

On 12/02/16 08:23, Jan Beulich wrote: On 11.02.16 at 20:25, wrote: >> CentOS 7 gets into trouble when compiling Xen citing: >> >> flushtlb.c: Assembler messages: >> flushtlb.c:149: Error: value of 256 too large for field of 1 bytes at 1 >> >> The line number is

[Xen-devel] [PATCH net-next v1 4/8] xen-netback: reduce log spam

Remove the "prepare for reconnect" pr_info in xenbus.c. It's largely uninteresting and the states of the frontend and backend can easily be observed by watching the (o)xenstored log. Signed-off-by: Paul Durrant Cc: Ian Campbell Cc: Wei Liu

[Xen-devel] [PATCH net-next v1 3/8] xen-netback: support multiple extra info fragments passed from frontend

The code does not currently support a frontend passing multiple extra info fragments to the backend in a tx request. The xenvif_get_extras() function handles multiple extra_info fragments but make_tx_response() assumes there is only ever a single extra info fragment. This patch modifies

Re: [Xen-devel] [PATCH v2 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

On 02/12/2016 11:57 AM, Jan Beulich wrote: On 12.02.16 at 01:22, wrote: >> --- a/xen/arch/x86/vm_event.c >> +++ b/xen/arch/x86/vm_event.c >> @@ -122,6 +122,65 @@ void vm_event_set_registers(struct vcpu *v, >> vm_event_response_t *rsp) >> v->arch.user_regs.eip =

Re: [Xen-devel] [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs;

>>> On 12.02.16 at 04:08, wrote: > in the keyhandler.h file. Otherwise on ARM builds if we > just use the keyhandler file - the compile will fail. > > CC: ian.campb...@citrix.com > CC: wei.l...@citrix.com > CC: stefano.stabell...@citrix.com > Signed-off-by: Konrad

Re: [Xen-devel] [PATCH v2 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

>>> On 12.02.16 at 01:22, wrote: > Sending the dr7 register during vm_events is useful for various applications, > but the current way the register value is gathered is incorrent. In this > patch > we extend vmx_vmcs_save so that we get the correct value. > > Suggested-by:

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

>>> On 11.02.16 at 20:41, wrote: > On 11/02/16 19:25, Andrew Cooper wrote: >> --- a/xen/arch/x86/flushtlb.c >> +++ b/xen/arch/x86/flushtlb.c >> @@ -141,10 +141,10 @@ void flush_area_local(const void *va, unsigned int >> flags) >> { >>

Re: [Xen-devel] [PATCH v2 3/7] xen/vm-events: Move monitor_domctl to common-side.

On 2/12/2016 8:05 AM, Corneliu ZUZU wrote: On 2/11/2016 5:44 PM, Tamas K Lengyel wrote: * the #ifdefs make it possible for that code to be put in common => that makes it *clear* that those code parts are NOT architecture specific and their implementation can be safely used for

Re: [Xen-devel] [PATCH v2 4/6] xen: add capability to load initrd outside of initial mapping

Hey Juergen, On Fri, Feb 12, 2016 at 07:25:02AM +0100, Juergen Gross wrote: [...] > Okay, let me do some cleanup work on the xen loader: > > - add the possibility to call it multiple times (state reset, free the > allocated memory) > - merge all necessary global variables into one state

[Xen-devel] [PATCH] vm_event: Remove xc_mem_access_enable_emulate() and friends

xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate() are currently no-ops, that is all they do is set a flag that nobody else checks. The user can already set the EMULATE flags in the vm_event response if emulation is desired, and having an extra check above that is not inherently

Re: [Xen-devel] [PATCH 1/4] xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY

>>> On 11.02.16 at 22:10, wrote: > c/s 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 > "xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set." > would check the device for PCI_COMMAND_MEMORY which is great. > Except that VF devices are unique - for example they

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

On 12/02/16 10:00, Jan Beulich wrote: On 12.02.16 at 10:51, wrote: >> On 12/02/16 08:23, Jan Beulich wrote: >> On 11.02.16 at 20:25, wrote: CentOS 7 gets into trouble when compiling Xen citing: flushtlb.c: Assembler

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

>>> On 12.02.16 at 11:02, wrote: > On 12/02/16 10:00, Jan Beulich wrote: > On 12.02.16 at 10:51, wrote: >>> On 12/02/16 08:23, Jan Beulich wrote: >>> On 11.02.16 at 20:25, wrote: > CentOS 7 gets into

Re: [Xen-devel] [PATCH v2 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

>>> On 12.02.16 at 11:19, wrote: > On 02/12/2016 11:57 AM, Jan Beulich wrote: > On 12.02.16 at 01:22, wrote: >>> --- a/xen/arch/x86/vm_event.c >>> +++ b/xen/arch/x86/vm_event.c >>> @@ -122,6 +122,65 @@ void vm_event_set_registers(struct vcpu

Re: [Xen-devel] [PATCH v2 2/2] xen: credit1: avoid boosting vCPUs being "just" migrated

On Fri, 2016-02-12 at 02:50 -0700, Jan Beulich wrote: > > > > On 12.02.16 at 10:37, wrote: > > @@ -787,6 +788,16 @@ _csched_cpu_pick(const struct scheduler *ops, > > struct vcpu *vc, bool_t commit) > >  static int > >  csched_cpu_pick(const struct scheduler *ops, struct

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

On 12/02/16 10:12, Jan Beulich wrote: On 12.02.16 at 11:02, wrote: >> On 12/02/16 10:00, Jan Beulich wrote: >> On 12.02.16 at 10:51, wrote: On 12/02/16 08:23, Jan Beulich wrote: On 11.02.16 at 20:25,

Re: [Xen-devel] [PATCH] libxl: fix handling returns in libxl_get_version_info()

On Fri, 2016-02-12 at 16:22 +0530, Harmandeep Kaur wrote: > On Thu, Feb 11, 2016 at 3:18 PM, Dario Faggioli > wrote: > >  > > Another thing that you should check, and probably quickly mention > > too, > > is whether or not the callers of these functions --the ones

Re: [Xen-devel] [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs;

On Thu, 11 Feb 2016, Konrad Rzeszutek Wilk wrote: > in the keyhandler.h file. Otherwise on ARM builds if we > just use the keyhandler file - the compile will fail. > > CC: ian.campb...@citrix.com > CC: wei.l...@citrix.com > CC: stefano.stabell...@citrix.com > Signed-off-by: Konrad Rzeszutek Wilk

[Xen-devel] [xen-unstable-smoke test] 82125: tolerable all pass - PUSHED

flight 82125 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/82125/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

Re: [Xen-devel] [PATCH v2 4/6] xen: add capability to load initrd outside of initial mapping

On 11.02.2016 15:13, Juergen Gross wrote: > On 11/02/16 13:33, Daniel Kiper wrote: >> On Thu, Feb 11, 2016 at 08:53:24AM +0100, Juergen Gross wrote: >>> Modern pvops linux kernels support an initrd not covered by the initial >>> mapping. This capability is flagged by an elf-note. >>> >>> In case

Re: [Xen-devel] [PATCH v2] libxl: fix handling of returns in libxl_get_version_info()

On Fri, Feb 12, 2016 at 05:00:40PM +0530, Harmandeep Kaur wrote: > Check the return value of xc_version() and return NULL if it > fails. libxl_get_version_info() can also return NULL now. > Callers of the function libxl_get_version_info() are already > prepared to deal with returning NULL on

Re: [Xen-devel] [PATCH v3 2/5] arm/config: Declare ELFSIZE_[32|64] respectively.

On Thu, 11 Feb 2016, Konrad Rzeszutek Wilk wrote: > Otherwise any code that tries to use Elf_* macros instead of > Elf32_ or Elf_64 fails to compile. > > CC: ian.campb...@citrix.com > CC: wei.l...@citrix.com > CC: stefano.stabell...@citrix.com > Signed-off-by: Konrad Rzeszutek Wilk

[Xen-devel] [qemu-upstream-4.5-testing test] 81790: regressions - FAIL

flight 81790 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/81790/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 77858

Re: [Xen-devel] [PATCH v2 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

On Feb 12, 2016 03:41, "Jan Beulich" wrote: > > >>> On 12.02.16 at 11:19, wrote: > > On 02/12/2016 11:57 AM, Jan Beulich wrote: > > On 12.02.16 at 01:22, wrote: > >>> --- a/xen/arch/x86/vm_event.c > >>> +++

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

On 12/02/16 10:57, Jan Beulich wrote: On 12.02.16 at 11:50, wrote: >> On 12/02/16 10:12, Jan Beulich wrote: >> On 12.02.16 at 11:02, wrote: On 12/02/16 10:00, Jan Beulich wrote: On 12.02.16 at 10:51,

Re: [Xen-devel] [PATCH] libxl: fix handling returns in libxl_get_version_info()

On Fri, 2016-02-12 at 16:34 +0530, Harmandeep Kaur wrote: > On Fri, Feb 12, 2016 at 4:30 PM, Dario Faggioli > wrote: > >  > Sorry I actually meant, > tools/libxl/xl_cmdimpl.c:vinfo = libxl_get_version_info(ctx); > > vinfo = libxl_get_version_info(ctx); > if

Re: [Xen-devel] [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen

On Thu, 11 Feb 2016, Rafael J. Wysocki wrote: > On Thursday, February 11, 2016 04:04:14 PM Stefano Stabellini wrote: > > On Wed, 10 Feb 2016, Rafael J. Wysocki wrote: > > > On Tuesday, February 09, 2016 11:19:02 AM Stefano Stabellini wrote: > > > > On Mon, 8 Feb 2016, Rafael J. Wysocki wrote: > >

Re: [Xen-devel] [PATCH] libxl: fix handling returns in libxl_get_version_info()

On Thu, Feb 11, 2016 at 3:18 PM, Dario Faggioli wrote: > Hi Harmandeep, > > So, I think the code in this patch is ok. Still, a few comments... > > On Thu, 2016-02-11 at 14:00 +0530, Harmandeep Kaur wrote: >> Avoid handling issue of the return value of xc_version() in

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

From: Paul Durrant Date: Fri, 12 Feb 2016 10:13:17 + > This patch series adds support for frontend-configurable toeplitz hashing > in xen-netback (on the guest receive side). This support has been testing > against a Windows frontend and has proven to be sufficient

Re: [Xen-devel] [PATCH] libxl: fix handling returns in libxl_get_version_info()

On Fri, Feb 12, 2016 at 4:30 PM, Dario Faggioli wrote: > On Fri, 2016-02-12 at 16:22 +0530, Harmandeep Kaur wrote: >> On Thu, Feb 11, 2016 at 3:18 PM, Dario Faggioli >> wrote: >> > >> > Another thing that you should check, and probably

Re: [Xen-devel] Anyone know where the official qemu(1) man pages are hosted?

On Fri, 12 Feb 2016, Lars Kurth wrote: > I noticed that the qemu(1) links in > http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html (and probably other > docs) are broken. They go to http://man.he.net/man1/qemu, which does not > exist any more It doesn't look like QEMU maintains a

Re: [Xen-devel] [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs;

On Fri, 12 Feb 2016, Jan Beulich wrote: > >>> On 12.02.16 at 12:37, wrote: > > On Thu, 11 Feb 2016, Konrad Rzeszutek Wilk wrote: > >> --- a/xen/include/xen/keyhandler.h > >> +++ b/xen/include/xen/keyhandler.h > >> @@ -19,6 +19,7 @@ > >> */ > >> typedef void

Re: [Xen-devel] [PATCH v2] libxl: fix handling of returns in libxl_get_version_info()

On Fri, 2016-02-12 at 12:31 +, Wei Liu wrote: > On Fri, Feb 12, 2016 at 05:00:40PM +0530, Harmandeep Kaur wrote: > >  > > +info->xen_version_major = r >> 16; > > +info->xen_version_minor = r & 0xFF; > >   > > -xc_version(ctx->xch, XENVER_extraversion, _extra); > > +r =

Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

>>> On 12.02.16 at 11:50, wrote: > On 12/02/16 10:12, Jan Beulich wrote: > On 12.02.16 at 11:02, wrote: >>> On 12/02/16 10:00, Jan Beulich wrote: >>> On 12.02.16 at 10:51, wrote: > On 12/02/16 08:23,

[Xen-devel] [PATCH v3] libxc: fix leak of t_info in xc_tbuf_get_size()

Avoid leaking the memory mapping of the trace buffer Coverity ID 1351228 Signed-off-by: Harmandeep Kaur Reviewed-by: Dario Faggioli --- v2: call to unmapping function reduced to one from two v3: passed correct argument

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of David Miller > Sent: 12 February 2016 10:54 > To: Paul Durrant > Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org > Subject: Re: [PATCH net-next v1 0/8] xen-netback:

[Xen-devel] [PATCH v2] libxl: fix handling of returns in libxl_get_version_info()

Check the return value of xc_version() and return NULL if it fails. libxl_get_version_info() can also return NULL now. Callers of the function libxl_get_version_info() are already prepared to deal with returning NULL on failure of xc_version(). Coverity ID 1351217 Signed-off-by: Harmandeep Kaur

Re: [Xen-devel] [PATCH] vm_event: Remove xc_mem_access_enable_emulate() and friends

On Fri, Feb 12, 2016 at 11:04:34AM +0200, Razvan Cojocaru wrote: > xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate() > are currently no-ops, that is all they do is set a flag that > nobody else checks. The user can already set the EMULATE flags in > the vm_event response if

Re: [Xen-devel] [PATCH v2 3/6] xen: factor out allocation of page tables into separate function

On 11.02.2016 13:53, Juergen Gross wrote: > On 11/02/16 13:27, Daniel Kiper wrote: >> On Thu, Feb 11, 2016 at 08:53:23AM +0100, Juergen Gross wrote: >>> Do the allocation of page tables in a separate function. This will >>> allow to do the allocation at different times of the boot preparations >>>

Re: [Xen-devel] [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs;

>>> On 12.02.16 at 12:37, wrote: > On Thu, 11 Feb 2016, Konrad Rzeszutek Wilk wrote: >> --- a/xen/include/xen/keyhandler.h >> +++ b/xen/include/xen/keyhandler.h >> @@ -19,6 +19,7 @@ >> */ >> typedef void (keyhandler_fn_t)(unsigned char key); >> >> +struct

Re: [Xen-devel] [PATCH v3] libxc: fix leak of t_info in xc_tbuf_get_size()

On Fri, Feb 12, 2016 at 04:38:32PM +0530, Harmandeep Kaur wrote: > Avoid leaking the memory mapping of the trace buffer > > Coverity ID 1351228 > > Signed-off-by: Harmandeep Kaur > Reviewed-by: Dario Faggioli Acked-by: Wei Liu

Re: [Xen-devel] [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen

On Fri, Feb 12, 2016 at 12:50 PM, Stefano Stabellini wrote: > On Thu, 11 Feb 2016, Rafael J. Wysocki wrote: >> On Thursday, February 11, 2016 04:04:14 PM Stefano Stabellini wrote: >> > On Wed, 10 Feb 2016, Rafael J. Wysocki wrote: >> > > On Tuesday, February 09,

Re: [Xen-devel] [PATCH v2 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

On Feb 12, 2016 02:12, "Jan Beulich" wrote: > > >>> On 12.02.16 at 01:22, wrote: > > Sending the dr7 register during vm_events is useful for various applications, > > but the current way the register value is gathered is incorrent. In this > > patch > >

Re: [Xen-devel] [PATCH v3 2/5] arm/config: Declare ELFSIZE_[32|64] respectively.

On Fri, Feb 12, 2016 at 11:26:10AM +, Stefano Stabellini wrote: > On Thu, 11 Feb 2016, Konrad Rzeszutek Wilk wrote: > > Otherwise any code that tries to use Elf_* macros instead of > > Elf32_ or Elf_64 fails to compile. > > > > CC: ian.campb...@citrix.com > > CC: wei.l...@citrix.com > > CC:

Re: [Xen-devel] [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs;

>>> On 12.02.16 at 15:06, wrote: > On Fri, Feb 12, 2016 at 01:51:28AM -0700, Jan Beulich wrote: >> >>> On 12.02.16 at 04:08, wrote: >> > in the keyhandler.h file. Otherwise on ARM builds if we >> > just use the keyhandler file - the compile will

Re: [Xen-devel] [PATCH v3 2/5] arm/config: Declare ELFSIZE_[32|64] respectively.

>>> On 12.02.16 at 15:17, wrote: > --- a/xen/include/asm-arm/config.h > +++ b/xen/include/asm-arm/config.h > @@ -15,8 +15,10 @@ > > #if defined(CONFIG_ARM_64) > # define LONG_BYTEORDER 3 > +# define ELFSIZE 64 > #else > # define LONG_BYTEORDER 2 > +# define ELFSIZE

Re: [Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

>>> On 12.02.16 at 15:59, wrote: > Coverity correctly identifies that the changes in mtrr_attrib_to_str() > introduce dead code. strings[] is a 2d array, rather than an array of > strings, which means that strings[x] will never be a NULL pointer. > > Adjust the check

Re: [Xen-devel] xl dev-detach hangs with missing frontends

CC'ing other tools maintainer. On Thu, Feb 11, 2016 at 11:37:49AM +0100, Olaf Hering wrote: > How should libxl__initiate_device_generic_remove deal with devices which I think you meant libxl__initiate_device_remove. There is no function called libxl__initiate_device_generic _remove. > have no

[Xen-devel] [COVERITY ACCESS] Request for access to Coverity

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree to the conditions in the XenProject Coverity contribution guidelines [0]. I'm a developer working for Citrix Systems UK, Ltd. I've been active in the Xen community since 2008; I currently maintain Xen on ARM, Xen support for the ARM and

Re: [Xen-devel] [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs;

>>> On 12.02.16 at 13:46, wrote: > On Fri, 12 Feb 2016, Jan Beulich wrote: >> and then this is the "include everything everywhere" attitude >> which tends to needlessly slow down builds (avoiding the need >> to include everything everywhere is actually one of the

[Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

Coverity correctly identifies that the changes in mtrr_attrib_to_str() introduce dead code. strings[] is a 2d array, rather than an array of strings, which means that strings[x] will never be a NULL pointer. Adjust the check to compenstate, by looking for a NUL in strings[x][0] instead.

Re: [Xen-devel] [PATCH v3 3/5] build: remove .config from /boot when uninstalling.

On 2/11/16 9:08 PM, Konrad Rzeszutek Wilk wrote: > c/s 361b4f9f0f0d4adc19df428e224a7b8fa62cd392 > "build: save generated xen .config" forgot to remove > the config file when uninstalling. > > CC: ian.campb...@citrix.com > CC: jbeul...@suse.com > CC: car...@cardoe.com > CC:

Re: [Xen-devel] [PATCH v2 2/2] xen: credit1: avoid boosting vCPUs being "just" migrated

[Yes, replying to myself] On Fri, 2016-02-12 at 11:50 +0100, Dario Faggioli wrote: > On Fri, 2016-02-12 at 02:50 -0700, Jan Beulich wrote: > > > > > On 12.02.16 at 10:37, wrote: > > > @@ -787,6 +788,16 @@ _csched_cpu_pick(const struct scheduler > > > *ops, > > > struct

Re: [Xen-devel] [COVERITY ACCESS] Request for access to Coverity

On 12/02/16 14:53, Stefano Stabellini wrote: > I agree to the conditions in the XenProject Coverity contribution > guidelines [0]. > > I'm a developer working for Citrix Systems UK, Ltd. I've been active > in the Xen community since 2008; I currently maintain Xen on ARM, Xen > support for the ARM

Re: [Xen-devel] [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs;

On Fri, Feb 12, 2016 at 01:51:28AM -0700, Jan Beulich wrote: > >>> On 12.02.16 at 04:08, wrote: > > in the keyhandler.h file. Otherwise on ARM builds if we > > just use the keyhandler file - the compile will fail. > > > > CC: ian.campb...@citrix.com > > CC:

Re: [Xen-devel] [PATCH v2 4/6] xen: add capability to load initrd outside of initial mapping

On 12/02/16 13:24, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 11.02.2016 15:13, Juergen Gross wrote: >> On 11/02/16 13:33, Daniel Kiper wrote: >>> On Thu, Feb 11, 2016 at 08:53:24AM +0100, Juergen Gross wrote: Modern pvops linux kernels support an initrd not covered by the initial

[Xen-devel] [distros-debian-jessie test] 38740: tolerable all pass

flight 38740 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38740/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail never pass

Re: [Xen-devel] xl dev-detach hangs with missing frontends

On Fri, Feb 12, Wei Liu wrote: > CC'ing other tools maintainer. > > On Thu, Feb 11, 2016 at 11:37:49AM +0100, Olaf Hering wrote: > > How should libxl__initiate_device_generic_remove deal with devices which > > I think you meant libxl__initiate_device_remove. There is no function > called

Re: [Xen-devel] [PATCH v2 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

>>> On 12.02.16 at 13:50, wrote: > On Feb 12, 2016 03:41, "Jan Beulich" wrote: >> In which case ASSERT(is_hvm_vcpu(curr)) would be the common >> way to document this (at once avoiding the open coding of >> is_hvm_vcpu()). >> > > I don't think we need an

[Xen-devel] [qemu-upstream-4.6-testing test] 81798: regressions - FAIL

flight 81798 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/81798/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 77722

Re: [Xen-devel] [PATCH v2 2/6] relocator: Do not use memory region if its starta is smaller than size

Applied, thanks On 20.07.2015 16:35, Daniel Kiper wrote: > malloc_in_range() should not use memory region if its starta is smaller > than size. Otherwise target wraps around and points to region which is > usually not a RAM, e.g.: > > loader/multiboot.c:93: segment 0: paddr=0x80,

Re: [Xen-devel] [PATCH v2 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

>>> On 12.02.16 at 01:22, wrote: > --- a/xen/arch/x86/hvm/event.c > +++ b/xen/arch/x86/hvm/event.c > @@ -23,40 +23,9 @@ > #include > #include > #include > +#include > #include > > -static void hvm_event_fill_regs(vm_event_request_t *req) > -{ > -const struct

Re: [Xen-devel] [PATCH v2 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

>>> On 12.02.16 at 01:22, wrote: > --- a/xen/arch/x86/vm_event.c > +++ b/xen/arch/x86/vm_event.c > @@ -122,6 +122,65 @@ void vm_event_set_registers(struct vcpu *v, > vm_event_response_t *rsp) > v->arch.user_regs.eip = rsp->data.regs.x86.rip; > } > > +void

Re: [Xen-devel] [PATCH] xen/common: Uniformally use __ varients for attribute names

On 12/02/16 09:16, Jan Beulich wrote: On 11.02.16 at 20:51, wrote: >> Otherwise, debug code such as "void __attribute__((noreturn)) foobar()" fails >> to compile when the noreturn itself gets expanded, resulting in >> __attribute__((__attribute__((noreturn. >

[Xen-devel] [PATCH net-next v1 2/8] xen-netback: re-import canonical netif header

The canonical netif header (in the Xen source repo) and the Linux variant have diverged significantly. Recently much documentation has been added to the canonical header and new definitions and types to support packet hash configuration. Subsequent patches in this series add support for packet

[Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

This patch series adds support for frontend-configurable toeplitz hashing in xen-netback (on the guest receive side). This support has been testing against a Windows frontend and has proven to be sufficient to pass the Microsoft HCK NDIS RSS tests. For convenience my development branch is

[Xen-devel] [PATCH net-next v1 8/8] xen-netback: use toeplitz hash value from the frontend

This patch adds code to xen-netback to use the value in a toeplitz hash extra info fragment passed from the VM frontend in a transmit-side packet to set the skb hash accordingly. Signed-off-by: Paul Durrant Cc: Ian Campbell Cc: Wei Liu

[Xen-devel] [PATCH net-next v1 7/8] xen-netback: pass toeplitz hash value to the frontend

My recent patch to include/xen/interface/io/netif.h defines a new extra info type that can be used to pass toeplitz hash values between backend and VM frontend. This patch adds code to xen-netback to pass hash values calculated for receive-side packets to the VM frontend. Signed-off-by: Paul

[Xen-devel] [PATCH net-next v1 5/8] xen-netback: add support for the control ring

My recent patch to include/xen/interface/io/netif.h defines a new shared ring (in addition to the rx and tx rings) for passing control messages from a VM frontend driver to a backend driver. This patch adds the necessary code to xen-netback to map this new shared ring, should it be created by a

[Xen-devel] [PATCH net-next v1 6/8] xen-netback: add an implementation of toeplitz hashing...

...for receive-side packets. My recent patch to include/xen/interface/io/netif.h defines a set of control messages that can be used by a VM frontend driver to configure toeplitz hashing of receive-side packets and consequent steering of those packets to particular queues. This patch introduces

[Xen-devel] [PATCH net-next v1 1/8] skbuff: store hash type in socket buffer...

...rather than a boolean merely indicating a canonical L4 hash. skb_set_hash() takes a hash type (from enum pkt_hash_types) as an argument but information is lost since only a single bit in the skb stores whether that hash type is PKT_HASH_TYPE_L4 or not. By using two bits it's possible to store

Re: [Xen-devel] [PATCH v2 08/30] xen/x86: Mask out unknown features from Xen's capabilities

>>> On 05.02.16 at 14:42, wrote: > --- /dev/null > +++ b/xen/arch/x86/cpuid.c > @@ -0,0 +1,19 @@ > +#include > +#include > + > +const uint32_t known_features[] = INIT_KNOWN_FEATURES; > + > +static void __maybe_unused build_assertions(void) > +{ > +

Re: [Xen-devel] [PATCH v2 06/30] xen/x86: Script to automatically process featureset information

On 12/02/16 16:36, Jan Beulich wrote: On 05.02.16 at 14:41, wrote: >> This script consumes include/public/arch-x86/cpufeatureset.h and generates a >> single include/asm-x86/cpuid-autogen.h containing all the processed >> information. >> >> Signed-off-by: Andrew

Re: [Xen-devel] [PATCH v2 09/30] xen/x86: Store antifeatures inverted in a featureset

>>> On 05.02.16 at 14:42, wrote: > Awkwardly, some new feature bits mean "Feature $X no longer works". > Store these inverted in a featureset. > > This permits safe zero-extending of a smaller featureset as part of a > comparison, and safe reasoning (subset?,

Re: [Xen-devel] [PATCH v2 09/30] xen/x86: Store antifeatures inverted in a featureset

On 12/02/16 16:47, Jan Beulich wrote: On 05.02.16 at 14:42, wrote: >> Awkwardly, some new feature bits mean "Feature $X no longer works". >> Store these inverted in a featureset. >> >> This permits safe zero-extending of a smaller featureset as part of a >>

Re: [Xen-devel] [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

>>> On 05.02.16 at 14:42, wrote: > Use attributes to specify whether a feature is applicable to be exposed to: > 1) All guests > 2) HVM guests > 3) HVM HAP guests No provisions for PV-only or shadow-only features? > +#define X86_FEATURE_MTRR ( 0*32+12) /*S

Re: [Xen-devel] [PATCH v2 08/30] xen/x86: Mask out unknown features from Xen's capabilities

>>> On 12.02.16 at 17:48, wrote: > On 12/02/16 16:43, Jan Beulich wrote: > On 05.02.16 at 14:42, wrote: >>> --- /dev/null >>> +++ b/xen/arch/x86/cpuid.c >>> @@ -0,0 +1,19 @@ >>> +#include >>> +#include >>> + >>> +const uint32_t

[Xen-devel] Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

Hey, Fedora for the longest time seems to have two linkers - one normal for GNU applications and then another - mingw64 - for building EFI applications. Which means that to compile ELF binaries on Fedora requires this patch (taken from Fedora build): >From

[Xen-devel] [PULL 0/5] tags/xen-2016-02-12

The following changes since commit f075c89f0a9cb31daf38892371d2822177505706: Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging (2016-02-09 17:56:46 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git

Re: [Xen-devel] xl dev-detach hangs with missing frontends

On Fri, Feb 12, 2016 at 03:53:06PM +0100, Olaf Hering wrote: > On Fri, Feb 12, Wei Liu wrote: > > > CC'ing other tools maintainer. > > > > On Thu, Feb 11, 2016 at 11:37:49AM +0100, Olaf Hering wrote: > > > How should libxl__initiate_device_generic_remove deal with devices which > > > > I think

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: 12 February 2016 16:42 > To: Paul Durrant > Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org > Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing > > From: Paul Durrant

Re: [Xen-devel] [PATCH v3] travis: add initial Travis CI script to do builds [and 2 more messages]

Doug Goldstein writes ("[PATCH v3] travis: add initial Travis CI script to do builds"): > This is just suppose to do a simple compile test on Travis CI. Currently > due to linux86 (bcc/bin86/dev86) not being whitelisted the tools cannot > be built. > > Signed-off-by: Doug Goldstein

Re: [Xen-devel] [PATCH v8 4/5] vscsiif.h: add some notes about xenstore layout

On Thu, Feb 11, 2016 at 03:43:30PM +, Olaf Hering wrote: > Signed-off-by: Olaf Hering > Acked-by: Ian Campbell > Cc: Ian Campbell > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Keir

Re: [Xen-devel] [PATCH v8 1/5] vscsiif.h: fix WWN notation for p-dev property

On Thu, Feb 11, 2016 at 03:43:27PM +, Olaf Hering wrote: > The pvops kernel expects either "naa.WWN:LUN" or "h:c:t:l" in the p-dev > property. Add the missing :LUN part to the comment. > > Signed-off-by: Olaf Hering > Acked-by: Ian Campbell > Cc: Ian

Re: [Xen-devel] [PATCH v8 5/5] Scripts to create and delete xen-scsiback nodes in Linux target framework

On Thu, Feb 11, 2016 at 03:43:31PM +, Olaf Hering wrote: > Just to make them public, not meant for merging: I might be mistaken, but if you don't provide a hotplug script or some sort for Xen how do you expect user to make use vscsi? Wei. ___

Re: [Xen-devel] [PATCH v2 08/30] xen/x86: Mask out unknown features from Xen's capabilities

On 12/02/16 16:43, Jan Beulich wrote: On 05.02.16 at 14:42, wrote: >> --- /dev/null >> +++ b/xen/arch/x86/cpuid.c >> @@ -0,0 +1,19 @@ >> +#include >> +#include >> + >> +const uint32_t known_features[] = INIT_KNOWN_FEATURES; >> + >> +static void __maybe_unused

Re: [Xen-devel] [PATCH v2 09/30] xen/x86: Store antifeatures inverted in a featureset

>>> On 12.02.16 at 17:50, wrote: > On 12/02/16 16:47, Jan Beulich wrote: > On 05.02.16 at 14:42, wrote: >>> Awkwardly, some new feature bits mean "Feature $X no longer works". >>> Store these inverted in a featureset. >>> >>> This permits

Re: [Xen-devel] [PATCH v8 3/5] libxl: add support for vscsi

I notice you posted several enquiries in your previous patch, but I'm not sure if any of them still requires answers because you seemed to have posted answers to your own enquiries. I skip all of them and start from this version. There seems to be a lot of places in this patch where the lines are

  1   2   >