>>> 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)
>> {
>> alternative(ASM_NOP3, "sfence", X86_FEAT
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 a
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 struct
>>> 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. It turns out
> that the int
>>> 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 Rzeszutek Wilk
See commit d
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 saf
>>> 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 cpu_user_regs *regs = gu
>>> 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 0
> #define XENMEM_access_o
>>> 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: Andrew Cooper
Iirc A
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
>> #define XENMEM_access_o
>>> 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 plain "noreturn" then,
instea
>>> 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 have no
> legacy interrupt
>>> 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
> completing would overwrite op
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
---
Cc: George Dunlap
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
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@lists.xen.o
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
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
>>> flags)
>>> {
>>>
>>> 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);
> +
> +/*
> + * We
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 wrong, and the error messag
>>> 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 vm_event_fill_regs(vm_event_reque
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.
> Well, why would the debugging
>>> 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 of 256 too large for field of 1 bytes at 1
>>>
>>> The
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 messages:
flushtlb.c:149: Error: value of 256 to
>>> 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 trouble when compiling Xen citing:
>
> flushtlb.c: Assembler messages:
>>>
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 = rsp->data.regs.x86.rip;
>
...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
...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 an
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
hash
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 availabl
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
---
drivers/net/xen-netback/netback.c | 29 +++
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 Durr
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 fr
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
---
drivers/net/xen-netback/xenbus.c | 2 --
1 file ch
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 xenvif_get
>>> 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 *v,
> vm_event_response_t *rsp)
>>> v->arch.u
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 vcpu *vc)
> > {
> > +s
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, wrote:
>> CentOS 7 gets into trouble when compiling Xen citing:
>
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 many
>> cases.
>>
> This can b
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 to pass the
> Microsoft HCK
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
te
>>> 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, Jan Beulich wrote:
> On 11.02.16 at 20:25, wrote:
>>> CentOS 7 gets int
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 inside
> > xen.git of course-- ar
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 quickly mention
>> > too,
>> > is whether or not the callers
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 traditional
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, wrote:
>> On 12/02/16 08:23, Jan Beulich wrote:
>> On 11.02.1
> -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: sup
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 sysctl.u.tbuf_op.size in
xenforeignmemory_unmap()
---
tools/libxc/xc_t
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 (vinfo) {
>
Which again checks
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/i
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
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
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:
> > >
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
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 emulati
>>> 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 cpu_user_regs;
>> /*
>> * Callback
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
>>>
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 th
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 failur
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
Thanks
___
Xen-devel
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 (keyhandler_fn_t)(unsigned char key);
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
> >>> +++ b/xen/arch/x86/vm_event.c
> >>> @@ -122,6 +122,65 @@ void vm_event_set_registers(stru
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
> > we extend vmx_vmcs_save so that we get the
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, 2016 11:19:02 AM Stefano Stabellini
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, &u.xen_extra);
> > +r = xc_
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: wei.l...@citrix.com
> > CC: stefano.s
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 fr
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: ian.jack...@eu.citrix.co
[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 vcpu *vc, bool_t commit)
>
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: st
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
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
test-armhf-ar
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 libxl__
>>> 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
>> purposes of such forward declar
-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 ARM64
>>> 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 fail.
>> >
>> > CC: ian.campb...@citrix.com
>> >
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
>>> 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 assert here. The function is fine for pv g
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
t
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, memsz=0x3f800
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.
Curiousl
>>> On 12.02.16 at 13:57, wrote:
> 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
>> >
>>> 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 64
> #endif
Leaving the
>>> 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 to compenstate, by looking f
On 12/02/16 15:13, Jan Beulich wrote:
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.
>>
>> Ad
Hello,
Now that Clang 3.5 can build the hypervisor, I was just preparing a
patch to README, and encountered this:
In file included from xc_altp2m.c:23:
In file included from ./xc_private.h:35:
In file included from ./include/xenctrl.h:53:
/local/xen.git/tools/libxc/../../tools/include/xen/foreign
On Fri, 12 Feb 2016, Jan Beulich wrote:
> >>> 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 LON
On Fri, Feb 12, 2016 at 02:53:21PM +, Stefano Stabellini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [0].
+1
>
> I'm a developer working for Citrix Systems UK, Ltd. I've been active
> in the Xen
On Fri, Feb 12, 2016 at 03:26:14PM +, Stefano Stabellini wrote:
> On Fri, 12 Feb 2016, Jan Beulich wrote:
> > >>> 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)
>
On Fri, 12 Feb 2016, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 12, 2016 at 03:26:14PM +, Stefano Stabellini wrote:
> > On Fri, 12 Feb 2016, Jan Beulich wrote:
> > > >>> On 12.02.16 at 15:17, wrote:
> > > > --- a/xen/include/asm-arm/config.h
> > > > +++ b/xen/include/asm-arm/config.h
> > > > @
>>> On 12.02.16 at 16:25, wrote:
> Hello,
>
> Now that Clang 3.5 can build the hypervisor, I was just preparing a
> patch to README, and encountered this:
>
> In file included from xc_altp2m.c:23:
> In file included from ./xc_private.h:35:
> In file included from ./include/xenctrl.h:53:
> /local
On 12/02/16 16:04, Jan Beulich wrote:
On 12.02.16 at 16:25, wrote:
>> Hello,
>>
>> Now that Clang 3.5 can build the hypervisor, I was just preparing a
>> patch to README, and encountered this:
>>
>> In file included from xc_altp2m.c:23:
>> In file included from ./xc_private.h:35:
>> In file i
>>> On 05.02.16 at 14:41, wrote:
> +/* Intel-defined CPU features, CPUID level 0x0001.edx, word 0 */
> +#define X86_FEATURE_FPU ( 0*32+ 0) /* Onboard FPU */
Regardless of you limiting the interface to tools only, I'm not
convinced exposing constants starting with X86_* here is
app
Hi,
take 3 of this series. Only change wrt v2 is the atomic-safeness fix in patch
2.
While there, I've also added a comment about the need for such atomic-safeness
when accessing Credit1's svc->flags.
History is here:
v2: http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01750.htm
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
---
Cc: George Dunlap
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
>>> 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 Cooper
Acked-by: Jan Beulich
albeit ...
> --- /dev/null
> +++ b/xen/to
>>> On 05.02.16 at 14:42, wrote:
> New words are:
> * 0x8007.edx - Contains Invarient TSC
> * 0x8008.ebx - Newly used for AMD Zen processors
>
> In addition, replace some open-coded ITSC and EFRO manipulation.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
flight 81861 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
version targeted
From: Paul Durrant
Date: Fri, 12 Feb 2016 11:07:50 +
> Windows *requires* use of Teoplitz so your position completely rules
> out being able to support receive side scaling in Windows PV
> frontends on Linux kernel backends, not only for Xen but for any
> other hypervisor, which I think is to
1 - 100 of 186 matches
Mail list logo
