>>> On 12.02.16 at 21:40, wrote:
>> > diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
>> > index 96680eb..d549e7a 100644
>> > --- a/xen/include/public/sysctl.h
>> > +++ b/xen/include/public/sysctl.h
>> > @@ -766,6 +766,160 @@ struct xen_sysctl_tmem_op {
>> > typedef struct
On 15/02/2016 07:36, Jan Beulich wrote:
> Even if placed in .init.* there's no reason to needlessly bloat the
> binary due to padding fields the compiler needs to insert on 64-bit
> architectures.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 15/02/2016 07:42, Jan Beulich wrote:
> @@ -5395,7 +5398,7 @@ int hvm_do_hypercall(struct cpu_user_reg
> }
> #endif
>
> -regs->_eax = hvm_hypercall32_table[eax](ebx, ecx, edx, esi, edi,
> ebp);
> +regs->_eax = hypercall_table[eax].compat(ebx, ecx, edx, esi, edi,
> eb
On 02/15/2016 08:35 AM, Corneliu ZUZU wrote:
> This patch merges almost identical functions hvm_event_int3 and
> hvm_event_single_step into a single function called hvm_event_breakpoint.
> Also fixes event.c file header comment in the process.
>
> Signed-off-by: Corneliu ZUZU
> ---
> xen/arch/x8
>>> On 12.02.16 at 19:05, wrote:
> --- a/xen/include/xen/elfstructs.h
> +++ b/xen/include/xen/elfstructs.h
> @@ -348,6 +348,14 @@ typedef struct {
> #define ELF64_R_TYPE(info) ((info) & 0x)
> #define ELF64_R_INFO(s,t)(((s) << 32) + (u_int32_t)(t))
>
> +/* x86-64 relocatio
Hi,
> 1.9-stable created now, with the patch above cherry-picked.
1.9.1 tagged & tarball uploaded now.
cheers,
Gerd
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
> > 3. Design of vNVDIMM in Xen
>
> Thank you for this design!
>
> >
> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
> > three parts:
> > (1) Guest clwb/clflushopt/pcommit enabling,
> > (2) Memory mapping, and
> > (3)
On 2/15/2016 8:37 AM, Corneliu ZUZU wrote:
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
new file mode 100644
index 000..b708cab
--- /dev/null
+++ b/xen/common/monitor.c
+int rc;
+bool_t requested_status = 0;
+
+if ( unlikely(current->domain == d) ) /* no domain_pause()
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: 14 February 2016 22:02
> To: Paul Durrant
> Cc: David Miller; net...@vger.kernel.org; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing
>
> On Fri, Feb 1
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: 14 February 2016 22:25
> To: Paul Durrant
> Cc: Linux Kernel Network Developers; xen-de...@lists.xenproject.org; David
> S. Miller; Jay Vosburgh; Veaceslav Falico; Andy Gospodarek
> Subject: Re: [PATCH net-next v
>>> On 15.02.16 at 09:26, wrote:
> On 15/02/2016 07:42, Jan Beulich wrote:
>> @@ -5395,7 +5398,7 @@ int hvm_do_hypercall(struct cpu_user_reg
>> }
>> #endif
>>
>> -regs->_eax = hvm_hypercall32_table[eax](ebx, ecx, edx, esi, edi,
>> ebp);
>> +regs->_eax = hypercall_table
On 02/03/16 23:47, Konrad Rzeszutek Wilk wrote:
> > > > > Open: It seems no system call/ioctl is provided by Linux kernel to
> > > > >get the physical address from a virtual address.
> > > > >/proc//pagemap provides information of mapping from
> > > > >VA to PA. Is it an ac
> -Original Message-
> From: qemu-devel-bounces+paul.durrant=citrix@nongnu.org
> [mailto:qemu-devel-bounces+paul.durrant=citrix@nongnu.org] On
> Behalf Of Wei Liu
> Sent: 12 February 2016 19:11
> To: qemu-de...@nongnu.org; Xen-devel
> Cc: Anthony Perard; gk...@linux.vnet.ibm.com; We
>>> On 12.02.16 at 18:42, wrote:
> On 12/02/16 17:05, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> +#define X86_FEATURE_VMXE ( 1*32+ 5) /*S Virtual Machine
>>> Extensions */
>> Shouldn't this get a "nested-only" class?
>
> I am not sure that would be appropriate. On the
>>> On 12.02.16 at 18:19, wrote:
> 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):
This se
A sample Gentoo compliation of Xen contains
lea-0x1058(%rsp),%rsp
orq$0x0,(%rsp)
lea0x1020(%rsp),%rsp
Whatever the reason for silly code like this, it fools the current stack
overflow detection logic in the #DF handler (which triggers reliably on the
'orq' instruction).
U
Hey, Harmandeep,
We're almost there, I would say.
The subject is still suboptimal, IMO. I would go for something like
"libxl: handle failure of xc_version() in libxl_get_version_info()
The changelog...
On Sat, 2016-02-13 at 02:05 +0530, Harmandeep Kaur wrote:
> Check the return value of xc_ver
This patch modified the control ring protocol (of which there is
not yet an implementation) to make it more general. Most of the
concepts are not limited to toeplitz hashing so it's best not to
make them unnecessarily specific.
Apart from changing the names of various definitions and modifying
com
flight 82516 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82516/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 82212
build-amd64-rumpuserxen
>>> On 15.02.16 at 09:43, wrote:
> On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
>> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
>> > three parts:
>> > (1) Guest clwb/clflushopt/pcommit enabling,
>> > (2) Memory mapping, and
>> > (3) Guest ACPI emulation.
>>
>>
>>> On 15.02.16 at 11:17, wrote:
> +#define NETIF_CTRL_HASH_ALGORITHM_TOEPLITZ 1
> +
> +/*
> + * This algorithm uses a 'key' as well as the data buffer itself.
> + * (Buffer[] and Key[] are treated as shift-registers where the MSB of
> + * Buffer/Key[0] is considered 'left-most' and the LSB of Buf
>>> On 14.02.16 at 09:38, 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 emulation is desired, and having an ex
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 February 2016 11:13
> To: Paul Durrant
> Cc: Ian Campbell; Ian Jackson; xen-de...@lists.xenproject.org; Keir
> (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH] public/io/netif.h: make control ring hash protocol mo
On Mon, 15 Feb 2016, Jan Beulich wrote:
> >>> On 14.02.16 at 09:38, 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
This patch modified the control ring protocol (of which there is
not yet an implementation) to make it more general. Most of the
concepts are not limited to toeplitz hashing so it's best not to
make them unnecessarily specific.
Apart from changing the names of various definitions and modifying
com
On Sun, Feb 14, 2016 at 10:38:58AM +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 15.02.16 at 07:37, wrote:
> default:
> -return -EOPNOTSUPP;
> +/*
> + * Should not be reached unless arch_monitor_get_capabilities() is
> not
> + * properly implemented. In that case, since reaching this point does
> + * not really break anythin
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://g
On Sun, 14 Feb 2016, Paul Gortmaker wrote:
> Code that uses no modular facilities whatsoever should not be
> sourcing module.h at all, since that header drags in a bunch
> of other headers with it.
>
> Similarly, code that is not explicitly using modular facilities
> like module_init() but only is
On Sun, 14 Feb 2016, Paul Gortmaker wrote:
> The Makefile / Kconfig currently controlling compilation here is:
>
> obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o
> [...]
> obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o
>
> ...with:
>
> drivers/xen/Kconfig:config X
On Sun, 14 Feb 2016, Paul Gortmaker wrote:
> The Makefile / Kconfig currently controlling compilation here is:
>
> obj-y += xenbus_dev_frontend.o
> [...]
> obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
>
> ...with:
>
> drivers/xen/Kconfig:config XEN_BACKEND
> drivers/xen/Kconfig:bool "
On Sun, 14 Feb 2016, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> config XEN_SYS_HYPERVISOR
>bool "Create xen entries under /sys/hypervisor"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modula
On Sun, 14 Feb 2016, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> arch/x86/xen/Kconfig:config XEN_PVHVM
> arch/x86/xen/Kconfig: def_bool y
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modular code t
On Fri, Feb 12, 2016 at 07:21:31PM +, Andrew Cooper wrote:
> c/s de0f8c7c changed the use of zlib-options, and moved it from being locally
> generated to coming from ./configure.
>
Wow, this is ancient commit.
> However, it neglected to modify the users of zlib-options. The curious use of
>
... and hence the respective {read,write}_msr() hook parameter doesn't
need to be "unsigned long".
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -966,7 +966,7 @@ static int hvmemul_write_io_discard(
}
static int hvmemul_write_msr_discard(
-
AAM/AAD as well as DAA/DAS emulation code is respectively almost
identical. Fold each pair, following what's already the case for
AAA/AAS.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2053,46 +2053,25 @@ x86_emulate(
Let's give the compiler as much liberty in picking instruction operands
as possible. Also drop unnecessary size modifiers when the correct size
can already be derived from the asm() operands. Finally also drop an
"unsigned" from idiv_dbl()'s second parameter, allowing a cast to be
eliminated.
Sign
Only return true from xen_is_pirq_msi when Xen is enabled: the function
should never identify an MSI as Xen pirq when not running on Xen.
Signed-off-by: Stefano Stabellini
CC: m...@redhat.com
CC: berra...@redhat.com
CC: xen-devel@lists.xen.org
---
hw/pci/msix.c |2 +-
xen-hvm.c |3 ++
On 2/15/2016 1:41 PM, Jan Beulich wrote:
On 15.02.16 at 07:37, wrote:
default:
-return -EOPNOTSUPP;
+/*
+ * Should not be reached unless arch_monitor_get_capabilities() is not
+ * properly implemented. In that case, since reaching this point does
+
On 2/15/2016 1:41 PM, Jan Beulich wrote:
+++ b/xen/include/xen/monitor.h
@@ -0,0 +1,30 @@
+/*
+ * include/xen/monitor.h
+ *
+ * Common monitor_op domctl handler.
+ *
+ * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
+ * Copyright (c) 2016, Bitdefender S.R.L.
+ *
+ * This program is fre
On Mon, 15 Feb 2016, Jan Beulich wrote:
> >>> On 15.02.16 at 07:37, wrote:
> > default:
> > -return -EOPNOTSUPP;
> > +/*
> > + * Should not be reached unless arch_monitor_get_capabilities() is
> > not
> > + * properly implemented. In that case, since reaching
On Fri, Feb 12, 2016 at 01:05:40PM -0500, Konrad Rzeszutek Wilk wrote:
> The underlaying toolstack code to do the basic
> operations when using the XEN_XSPLICE_op syscalls:
> - upload the payload,
> - get status of an payload,
> - list all the payloads,
> - apply, check, replace, and revert the
On 2/15/2016 2:25 PM, Stefano Stabellini wrote:
On Mon, 15 Feb 2016, Jan Beulich wrote:
On 15.02.16 at 07:37, wrote:
default:
-return -EOPNOTSUPP;
+/*
+ * Should not be reached unless arch_monitor_get_capabilities() is not
+ * properly implemented. In that
>>> On 15.02.16 at 13:14, wrote:
> On 2/15/2016 1:41 PM, Jan Beulich wrote:
> On 15.02.16 at 07:37, wrote:
>>> default:
>>> -return -EOPNOTSUPP;
>>> +/*
>>> + * Should not be reached unless arch_monitor_get_capabilities() is
>>> not
>>> + * properly impl
On Fri, Feb 12, 2016 at 01:05:52PM -0500, Konrad Rzeszutek Wilk wrote:
> If the hypervisor is built with we will display it.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
> v3: Retry with different size if 1020 is not enough.
> ---
> tools/libxl
On 15/02/16 11:57, Jan Beulich wrote:
> ... and hence the respective {read,write}_msr() hook parameter doesn't
> need to be "unsigned long".
>
> Signed-off-by: Jan Beulich
I would suggest uint32_t instead (being more architecturally
self-documenting), but either way, Reviewed-by: Andrew Cooper
On Fri, Feb 12, 2016 at 01:05:41PM -0500, Konrad Rzeszutek Wilk wrote:
[...]
> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> new file mode 100644
> index 000..13f762f
> --- /dev/null
> +++ b/tools/misc/xen-xsplice.c
One gripe I have with this program is that many of its fu
>>> On 15.02.16 at 13:51, wrote:
> On 15/02/16 11:57, Jan Beulich wrote:
>> ... and hence the respective {read,write}_msr() hook parameter doesn't
>> need to be "unsigned long".
>>
>> Signed-off-by: Jan Beulich
>
> I would suggest uint32_t instead (being more architecturally
> self-documenting),
On Mon, Feb 15, 2016 at 09:07:13AM +, Paul Durrant wrote:
> >
[...]
> > # Option 2: Invent a xen-9p device
> >
> > Another way of doing it is to expose a dummy xen-9p device, so that we
> > can use -fsdev XXX -device xen-9p,YYY. This simple device should be
> > used to capture the parameters
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 15 February 2016 13:16
> To: Paul Durrant
> Cc: Wei Liu; qemu-de...@nongnu.org; Xen-devel; Anthony Perard;
> gk...@linux.vnet.ibm.com; aneesh.ku...@linux.vnet.ibm.com; Stefano
> Stabellini
> Subject: Re: [Qemu-devel]
On 2/15/2016 2:44 PM, Jan Beulich wrote:
switch ( mop->op )
{
case XEN_DOMCTL_MONITOR_OP_ENABLE:
case XEN_DOMCTL_MONITOR_OP_DISABLE:
/* Check if event type is available. */
if ( unlikely(!(arch_monitor_get_capabilities(d) & (1 <<
mop->event))) )
On 15/02/16 12:00, Jan Beulich wrote:
> AAM/AAD as well as DAA/DAS emulation code is respectively almost
> identical. Fold each pair, following what's already the case for
> AAA/AAS.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-de
On 15/02/16 14:16, Wei Liu wrote:
> On Mon, Feb 15, 2016 at 09:07:13AM +, Paul Durrant wrote:
>>>
> [...]
>>> # Option 2: Invent a xen-9p device
>>>
>>> Another way of doing it is to expose a dummy xen-9p device, so that we
>>> can use -fsdev XXX -device xen-9p,YYY. This simple device should b
>>> On 05.02.16 at 14:42, wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -1,13 +1,165 @@
> #include
> #include
> +#include
> +#include
> +#include
> +
> +#define COMMON_1D INIT_COMMON_FEATURES
>
> const uint32_t known_features[] = INIT_KNOWN_FEATURES;
> const uint
On 15/02/16 12:06, Jan Beulich wrote:
> Let's give the compiler as much liberty in picking instruction operands
> as possible. Also drop unnecessary size modifiers when the correct size
> can already be derived from the asm() operands. Finally also drop an
> "unsigned" from idiv_dbl()'s second para
On Mon, Feb 15, 2016 at 02:33:05PM +0100, Juergen Gross wrote:
> On 15/02/16 14:16, Wei Liu wrote:
> > On Mon, Feb 15, 2016 at 09:07:13AM +, Paul Durrant wrote:
> >>>
> > [...]
> >>> # Option 2: Invent a xen-9p device
> >>>
> >>> Another way of doing it is to expose a dummy xen-9p device, so th
On Sat, Feb 13, 2016 at 08:23:14PM -0500, Boris Ostrovsky wrote:
> On 02/11/2016 04:10 PM, Konrad Rzeszutek Wilk wrote:
> >
> >This patch fixes the issue by:
> > 1) Use kzalloc to initialize to a well known state.
> > 2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
> > way acc
>>> On 05.02.16 at 14:42, wrote:
> @@ -20,12 +21,34 @@ uint32_t __read_mostly hvm_featureset[FSCAPINTS];
>
> static void sanitise_featureset(uint32_t *fs)
> {
> +uint32_t disabled_features[FSCAPINTS];
> unsigned int i;
>
> for ( i = 0; i < FSCAPINTS; ++i )
> {
> /
>>> On 15.02.16 at 14:29, wrote:
> On 2/15/2016 2:44 PM, Jan Beulich wrote:
>>
>>> switch ( mop->op )
>>> {
>>> case XEN_DOMCTL_MONITOR_OP_ENABLE:
>>> case XEN_DOMCTL_MONITOR_OP_DISABLE:
>>> /* Check if event type is available. */
>>> if ( unlikely(!(arc
Stefano Stabellini writes:
> Only return true from xen_is_pirq_msi when Xen is enabled: the function
> should never identify an MSI as Xen pirq when not running on Xen.
Is this supposed to fix ivshmem-test with SPEED=slow?
___
Xen-devel mailing list
X
On 12/02/16 00:22, Tamas K Lengyel wrote:
> Currently the registers saved in the request depend on which type of event
> is filling in the registers. In this patch we consolidate the two versions
> of register filling function as to return a fix set of registers irrespective
> of the underlying eve
>>> On 15.02.16 at 14:39, wrote:
> On 15/02/16 12:06, Jan Beulich wrote:
>> @@ -4542,9 +4542,10 @@ x86_emulate(
>>
>> case 0xbc: /* bsf or tzcnt */ {
>> bool_t zf;
>> -asm ( "bsf %2,%0; setz %b1"
>> +
>> +asm ( "bsf %2,%0; setz %1"
>>: "=r" (dst.val)
On Mon, Feb 15, 2016 at 02:32:45AM -0700, Jan Beulich wrote:
> >>> On 12.02.16 at 18:19, wrote:
> > 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 binar
On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote:
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -576,6 +578,7 @@ static void pcifront_free_roots(struct pcifront_device
> *pdev)
> free_root_bus_devs(bus_entry->bus);
>
> kfree(bus_entry->bus-
On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> These are patches that were developed for the Debian bug
> 810379 which san Tommi had openned.
>
> The issue around from the two XSA fixes - which introduced
> this regression.
Applied to for-linus-4.6, thanks.
I rewrote some of the com
All,
I am pleased to announce the release of Xen 4.6.1. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6
(tag RELEASE-4.6.1) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-4
On 15/02/16 14:35, David Vrabel wrote:
> On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote:
>> Hey,
>>
>> These are patches that were developed for the Debian bug
>> 810379 which san Tommi had openned.
>>
>> The issue around from the two XSA fixes - which introduced
>> this regression.
>
> Applied to
Switch from tracking a commit post 1.9.0 to the 1.9.1 release.
Signed-off-by: Doug Goldstein
---
Please make sure to sync git://xenbits.xen.org/seabios.git to
upstream prior to pushing this to staging.
---
Config.mk | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Conf
On 15/02/16 09:20, Jan Beulich wrote:
On 12.02.16 at 18:42, wrote:
>> On 12/02/16 17:05, Jan Beulich wrote:
>> On 05.02.16 at 14:42, wrote:
+#define X86_FEATURE_VMXE ( 1*32+ 5) /*S Virtual Machine
Extensions */
>>> Shouldn't this get a "nested-only" class?
>> I am no
flight 82560 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On 02/15/2016 09:05 AM, Konrad Rzeszutek Wilk wrote:
On Sat, Feb 13, 2016 at 08:23:14PM -0500, Boris Ostrovsky wrote:
On 02/11/2016 04:10 PM, Konrad Rzeszutek Wilk wrote:
This patch fixes the issue by:
1) Use kzalloc to initialize to a well known state.
2) Put 'struct pci_sysdata' at the st
>>> On 15.02.16 at 15:38, wrote:
> On 15/02/16 09:20, Jan Beulich wrote:
> On 12.02.16 at 18:42, wrote:
>>> On 12/02/16 17:05, Jan Beulich wrote:
>>> On 05.02.16 at 14:42, wrote:
> #define X86_FEATURE_MWAITX( 3*32+29) /* MWAIT extension
>>> (MONITORX/MWAITX) */
Why n
On 15/02/16 14:50, Jan Beulich wrote:
On 15.02.16 at 15:38, wrote:
>> On 15/02/16 09:20, Jan Beulich wrote:
>> On 12.02.16 at 18:42, wrote:
On 12/02/16 17:05, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> #define X86_FEATURE_MWAITX( 3*32+29) /* MWAIT ex
>>> On 05.02.16 at 14:42, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -53,8 +53,24 @@ static unsigned int cleared_caps[NCAPINTS];
>
> void __init setup_clear_cpu_cap(unsigned int cap)
> {
> + const uint32_t *dfs;
> + unsigned int i;
> +
> + if (
>>> On 05.02.16 at 14:42, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -53,8 +53,24 @@ static unsigned int cleared_caps[NCAPINTS];
>
> void __init setup_clear_cpu_cap(unsigned int cap)
> {
> + const uint32_t *dfs;
> + unsigned int i;
> +
> + if (
On 15/02/16 13:37, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -1,13 +1,165 @@
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>> +
>> +#define COMMON_1D INIT_COMMON_FEATURES
>>
>> const uint32_t kn
On 2/15/16 8:26 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 15, 2016 at 02:32:45AM -0700, Jan Beulich wrote:
> On 12.02.16 at 18:19, wrote:
>>> Fedora for the longest time seems to have two linkers - one normal for GNU
>>> applications and then another - mingw64 - for building EFI applicati
>>> On 15.02.16 at 15:53, wrote:
> On 15/02/16 14:50, Jan Beulich wrote:
> On 15.02.16 at 15:38, wrote:
>>> On 15/02/16 09:20, Jan Beulich wrote:
>>> On 12.02.16 at 18:42, wrote:
> On 12/02/16 17:05, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> #define X86_FEAT
>>> On 15.02.16 at 15:57, wrote:
> On 15/02/16 13:37, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -1,13 +1,165 @@
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define COMMON_1D
On 12/02/16 14:59, Andrew Cooper 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 loo
On Fri, Feb 12, 2016 at 07:24:59PM +0100, Olaf Hering wrote:
[...]
>
> > > +if (libxl__xs_directory(gc, XBT_NULL, be_path, &be_dirs)) {
> > > +rc = libxl__device_vscsi_reconfigure_add(egc, aodev,
> > > &vscsi_saved, &d_config, be_path);
> > > +if (rc)
> > > +goto o
El 12/2/16 a les 20:21, Andrew Cooper ha escrit:
> c/s de0f8c7c changed the use of zlib-options, and moved it from being locally
> generated to coming from ./configure.
>
> However, it neglected to modify the users of zlib-options. The curious use of
> $(call ...) was to select either the -D or -
On Mon, Feb 15, Wei Liu wrote:
> > I think yes, DEFINE_DEVICES_ADD has to be used somewhere.
> I'm confused. You're joking, right? "Has to be used somewhere" is not
> a justification for having it in this particular place.
What would be the appropriate place? I think its there since I started
wor
On 15/02/16 14:06, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> @@ -20,12 +21,34 @@ uint32_t __read_mostly hvm_featureset[FSCAPINTS];
>>
>> static void sanitise_featureset(uint32_t *fs)
>> {
>> +uint32_t disabled_features[FSCAPINTS];
>> unsigned int i;
>>
>> for ( i
On 15/02/16 14:53, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -53,8 +53,24 @@ static unsigned int cleared_caps[NCAPINTS];
>>
>> void __init setup_clear_cpu_cap(unsigned int cap)
>> {
>> +const uint32_t *d
On Mon, Feb 15, 2016 at 02:38:22PM +, David Vrabel wrote:
> On 15/02/16 14:35, David Vrabel wrote:
> > On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote:
> >> Hey,
> >>
> >> These are patches that were developed for the Debian bug
> >> 810379 which san Tommi had openned.
> >>
> >> The issue around
On 15/02/16 15:02, Jan Beulich wrote:
On 15.02.16 at 15:53, wrote:
>> On 15/02/16 14:50, Jan Beulich wrote:
>> On 15.02.16 at 15:38, wrote:
On 15/02/16 09:20, Jan Beulich wrote:
On 12.02.16 at 18:42, wrote:
>> On 12/02/16 17:05, Jan Beulich wrote:
>> On 05.02.1
>>> On 05.02.16 at 14:42, wrote:
> @@ -4617,50 +4618,39 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
> /* Fix up VLAPIC details. */
> *ebx &= 0x00FFu;
> *ebx |= (v->vcpu_id * 2) << 24;
> +
> +*ecx &= hvm_featureset[FEATURESET
On Mon, Feb 15, 2016 at 04:24:38PM +0100, Olaf Hering wrote:
> On Mon, Feb 15, Wei Liu wrote:
>
> > > I think yes, DEFINE_DEVICES_ADD has to be used somewhere.
> > I'm confused. You're joking, right? "Has to be used somewhere" is not
> > a justification for having it in this particular place.
>
>
On 15/02/16 15:07, Jan Beulich wrote:
>
+uint32_t __read_mostly raw_featureset[FSCAPINTS];
+uint32_t __read_mostly host_featureset[FSCAPINTS];
+uint32_t __read_mostly pv_featureset[FSCAPINTS];
+uint32_t __read_mostly hvm_featureset[FSCAPINTS];
+
+static void sanitise_f
>>> On 15.02.16 at 16:28, wrote:
> On 15/02/16 14:06, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> @@ -20,12 +21,34 @@ uint32_t __read_mostly hvm_featureset[FSCAPINTS];
>>>
>>> static void sanitise_featureset(uint32_t *fs)
>>> {
>>> +uint32_t disabled_features[FSCAPINTS];
>>>
Hey,
I wanted to ask what folks would think of expanding the Wiki to include (making
it a diff
for simpler) this change. With my giant 30 set of patches that not only CC-ed
xen-devel twice but had some patches CC some maintainers but not others - I
figured
it may be good to describe this in the
On 15/02/16 16:00, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> I wanted to ask what folks would think of expanding the Wiki to include
> (making it a diff
> for simpler) this change. With my giant 30 set of patches that not only CC-ed
> xen-devel twice but had some patches CC some maintainers but not
flight 82684 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82684/
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 15/02/16 15:52, Jan Beulich wrote:
>
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -138,6 +138,61 @@ def crunch_numbers(state):
state.hvm_shadow = featureset_to_uint32s(state.raw_hvm_shadow,
>> nr_entries)
state.hvm_hap = featureset_to_uint32s(s
El 15/2/16 a les 17:00, Konrad Rzeszutek Wilk ha escrit:
> Hey,
>
> I wanted to ask what folks would think of expanding the Wiki to include
> (making it a diff
> for simpler) this change. With my giant 30 set of patches that not only CC-ed
> xen-devel twice but had some patches CC some maintainer
On Mon, Feb 15, 2016 at 08:38:02AM -0600, Doug Goldstein wrote:
> Switch from tracking a commit post 1.9.0 to the 1.9.1 release.
>
Thanks for this patch.
We can't apply this patch just yet. We need to wait a bit until the
change to upstream trickles down to our own tree [0] -- OSSTest will
work o
On Fri, Feb 05, 2016 at 07:33:34PM +0100, Dario Faggioli wrote:
> as it is always acts on v->processor of the vcpu because
> of which we are tickling.
s/because of which// ?
>
> Getting rid of it makes the code easier to understand
> and better looking.
>
> While there, remove a spurious blank
On Mon, Feb 15, 2016 at 7:08 AM, Jan Beulich wrote:
> >>> On 15.02.16 at 14:29, wrote:
> > On 2/15/2016 2:44 PM, Jan Beulich wrote:
> >>
> >>> switch ( mop->op )
> >>> {
> >>> case XEN_DOMCTL_MONITOR_OP_ENABLE:
> >>> case XEN_DOMCTL_MONITOR_OP_DISABLE:
> >>> /*
On Fri, Feb 05, 2016 at 07:33:42PM +0100, Dario Faggioli wrote:
> vcpu_wake() and vcpu_sleep() are called before the specific
> schedulers wakeup and sleep routines (in fact, it is them
> that calls those specific routine).
Yeah!!
>
> Make the trace reflect that, by moving the records up. In
> f
1 - 100 of 170 matches
Mail list logo
