On 07/12/16 18:10, Ian Jackson wrote:
> Juergen Gross writes ("Xenstore domains and XS_RESTRICT"):
>> In order to solve the problem I suggest the following change to the
>> Xenstore wire protocol:
>>
>> struct xsd_sockmsg
>> {
>> -uint32_t type; /* XS_??? */
>> +uint16_t type; /* XS_???
Hi,
I am a newbie working on xen. I have brought up Dom0 in lager board. I want
to bring up Dom U in lager. I would like to know whether there are any
prebuilt binaries for xen dom0 modules for arm cortex a15 .
regards,
George
___
Xen-devel mailing list
X
On 07/12/16 18:00, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: Xenstore domains and XS_RESTRICT"):
>> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
>>> There is no socket connection to xenstore domain.
>>
>> Right but it creates its own XenStore ring. Can it send this x
flight 103062 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103062/
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 1
On 06/12/16 15:28, Konrad Rzeszutek Wilk wrote:
> The function is never called under PV guests, and only shows up
> when MSI (or MSI-X) cannot be allocated. Convert the message
> to include the error value.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Commited to xen/tip.git for-linus-4.10
Juergen
On 05/12/16 09:22, Pan Bian wrote:
> Variable err is initialized with 0. As a result, the return value may
> be 0 even if get_zeroed_page() fails to allocate memory. This patch fixes
> the bug, initializing err with "-ENOMEM".
>
> v1 is reviewed by: Juergen Gross
>
> Signed-off-by: Pan Bian
C
On 05/12/16 09:23, Pan Bian wrote:
> Variable rc is reset in the loop, and its value will be non-negative
> during the second and after repeat of the loop. If it fails to allocate
> memory then, it may return a non-negative integer, which indicates no
> error. This patch fixes the bug, assigning "-
> On Nov 30, 2016, at 9:50 PM, Andrew Cooper wrote:
>
> The current code to set up emulation state is ad-hoc and error prone.
>
> * Consistently zero all emulation state structures.
> * Avoid explicitly initialising some state to 0.
> * Explicitly identify all input and output state in x86_emul
On 07/12/16 19:29, Dario Faggioli wrote:
> Setting and getting the CPU class of a vCPU will happen via two new
> hypercalls:
>
> * `XEN_DOMCTL_setvcpuclass`
> * `XEN_DOMCTL_setvcpuclass`
XEN_DOMCTL_getvcpuclass
> ### Phase 2
>
> Inside Xen, the various schedulers will be modified to deal intern
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-trad
On 05/12/16 18:49, Alex Thorlton wrote:
> This is the third pass at my patchset to fix up our problems with
> XENMEM_machine_memory_map on large systems. The only changes on this
> pass were to flesh out the comment above the E820_X_MAX definition, and
> to add Juergen's Reviewed-by to the second
flight 103052 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103052/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3)broken REGR. vs.
branch xen-4.5-testing
xenbranch xen-4.5-testing
job test-xtf-amd64-amd64-2
testid leak-check/check
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xen
flight 103006 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103006/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt3 host-install(3) broken in 102751 REGR. vs. 10
flight 68168 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68168/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
68128
test-amd64-
On Wed, 7 Dec 2016, Julien Grall wrote:
> Hi all,
>
> Currently, it is only possible to start AArch32 guest with GICv2. This means
> that if the host interrupt controller is not compatible with GICv2, it will
> not be possible to boot AArch32 guest.
>
> The vGICv3 code is nearly fully compatible
On Wed, 7 Dec 2016, Julien Grall wrote:
> AArch32 guest will use co-processor registers to access the GICv3 (see
> 8.5 in IHI 0069C). Some of the registers have to be trapped and emulated
> (e.g ICC_SGI1R), this is the purpose of this patch.
>
> The rest of the emulation already supports access re
On Wed, 7 Dec 2016, Julien Grall wrote:
> The emulation of the co-processor register ICC_SGI1R is the same as the
> system register ICC_SGI1R_EL1. So move the emulation outside and use the
> newly introduced helper vreg_emulate_sysreg64 to abstract the access.
>
> Signed-off-by: Julien Grall
Rev
flight 103045 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103045/
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 1
On Wed, 7 Dec 2016, Julien Grall wrote:
> We will want to emulate co-processor registers access in a follow-up
> patch.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/vgic-v3.c | 13 -
> xen/arch/arm/vgic.c| 4 ++--
> xen/include/
On Wed, 7 Dec 2016, Julien Grall wrote:
> The core emulation of sysreg (reading/writing registers) is not specific
> to the virtual timer. Move the helpers in a new header vreg.h.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
>
> The helpers will be necessary in a foll
On Wed, 7 Dec 2016, Julien Grall wrote:
> Factorize the code to emulate 32-bit and 64-bit access to a co-processor
> in specific helpers.
>
> The new helpers will be used in different components to simplify the
> emulation.
>
> Finally, the prototypes for the callbacks to emulate 32-bit and 64-bi
This run is configured for baseline tests only.
flight 68167 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68167/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2c1cc12931b6c5a85471272799b3d4c249025a60
baseline v
On Wed, 7 Dec 2016, Julien Grall wrote:
> The vGICv3 depends whether Xen has a host driver for GICv3, not on the
> architecture (AArch64 vs AArch32).
>
> Note CONFIG_HAS_GICV3 is enabled only when for ARM64 build, so there is
> no functional change.
>
> Signed-off-by: Julien Grall
Reviewed-by:
On Wed, 7 Dec 2016, Julien Grall wrote:
> Couple of clean-up for the vgic sysreg emulation:
> - Reference the public documentation rather than a non-public one
> - Let the vgic emulation decides whether a register needs to be
> emulated
> - Drop unnecessary debug printk. They don't
flight 103007 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103007/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumprunbroken in 102952
build-i386-libvirt
On Wed, 7 Dec 2016, Stefano Stabellini wrote:
> On Wed, 7 Dec 2016, Julien Grall wrote:
> > vgic_v{2,3}_to_sgi.
> >
> > vgic_*to_sgi functions can only return 2 values: 0 or 1. Use bool instead
> > to make clear only two possible values exist.
> >
> > Signed-off-by: Julien Grall
>
> Reviewed-by
On Wed, 7 Dec 2016, Julien Grall wrote:
> emulate_sysreg callback can only return 2 values: 0 or 1. Use bool
> instead to make clear only two possible values exist.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/vgic-v3.c | 6 +++---
> xen/arch/arm/vgic.c
On Wed, 7 Dec 2016, Julien Grall wrote:
> vgic_v{2,3}_to_sgi.
>
> vgic_*to_sgi functions can only return 2 values: 0 or 1. Use bool instead
> to make clear only two possible values exist.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/vgic-v2.c | 4
On Wed, 7 Dec 2016, Julien Grall wrote:
> Since commit 9202342 "xen/build: Use C99 booleans", bool_t is an alias
> to bool. Going forward, therer is a preference to use bool rather than
> bool_t. Also replace 0 and 1 by false and true when relevant.
>
> Signed-off-by: Julien Grall
Reviewed-by: S
On Wed, 7 Dec 2016, Julien Grall wrote:
> Since commit 9202342 "xen/build: Use C99 booleans", bool_t is an alias
> to bool. Going forward, there is a preference to use bool rather than
> bool_t. Also replace 0 and 1 by true and false when relevant.
>
> Signed-off-by: Julien Grall
Reviewed-by: St
On Wed, 7 Dec 2016, Julien Grall wrote:
> The read variable can only take two values: 1 => read, 0 => write. Use
> bool instead to make clear the variable can only take 2 values.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/vtimer.c | 12 +++-
> 1 fi
On Wed, 7 Dec 2016, Julien Grall wrote:
> The emulation functions are always returning 0 or 1. Use bool instead to
> make clear only two possible values exist.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/vtimer.c | 60
> +---
On Wed, 7 Dec 2016, Julien Grall wrote:
> The function xen_guest_init is using __alloc_percpu with an alignment
> which are not power of two.
>
> However, the percpu allocator never supported alignments which are not power
> of two and has always behaved incorectly in thise case.
>
> Commit 3ca45
On Wed, Dec 07, 2016 at 08:37:29PM +, Andrew Cooper wrote:
> Hello,
>
> While digging around, it looks like there is some major bitrot of the PV
> autotranslate code.
>
> When constructing an autotranslate domain, tools/libxc/xc_dom_x86.c:
> x86_shadow() sets refcount | translate on the domai
Hello,
While digging around, it looks like there is some major bitrot of the PV
autotranslate code.
When constructing an autotranslate domain, tools/libxc/xc_dom_x86.c:
x86_shadow() sets refcount | translate on the domain.
The combination of translate != external was excluded by c/s
92942fd3d469
On Tue, 6 Dec 2016, Dario Faggioli wrote:
> On Tue, 2016-12-06 at 13:53 -0800, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Dario Faggioli wrote:
> > > Sorry if I can't be more useful than this for now. :-/
> >
> > We don't need scheduler support to implement interrupt migration. The
> > ques
On Tue, 6 Dec 2016, Julien Grall wrote:
> On 06/12/2016 22:01, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Stefano Stabellini wrote:
> > > moving a vCPU with interrupts assigned to it is slower than moving a
> > > vCPU without interrupts assigned to it. You could say that the
> > > slowness i
flight 103037 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103037/
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 1
Hi,
I am new in Xen environment and trying to get VMs running with the build
xen code base.
But, am facing issue bringing up the libvirt deamon. I have installed
latest unstable xen ( 4.9 ).
There seems to be a conflict in library version and because of which I am
getting below error :
...
Dec 08
On 07/12/16 17:28, Jan Beulich wrote:
On 07.12.16 at 17:18, wrote:
>> On 07/12/16 17:10, Sven Köhler wrote:
>>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
On 28/09/16 01:33, Sven Köhler wrote:
> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
>> On 27/09/16 14:09, Sven Köhler wr
On 07/12/16 17:33, Jan Beulich wrote:
On 07.12.16 at 17:10, wrote:
>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>>> On 28/09/16 01:33, Sven Köhler wrote:
Am 27.09.2016 um 14:52 schrieb Juergen Gross:
> On 27/09/16 14:09, Sven Köhler wrote:
>> Am 27.09.2016 um 14:02 schrieb Ju
On Wed, 2016-12-07 at 19:38 +0100, Dario Faggioli wrote:
> [DOC RFC] Heterogeneous Multi Processing Support in Xen
> <1481135379.3445.142.ca...@citrix.com>
>
> (I wanted to post a link to the message in the archives, but I'm not
> seeing it there yet... oh, well.)
>
It appeared:
https://lists.x
On Wed, 7 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 07/12/2016 19:02, Stefano Stabellini wrote:
> > Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
> > &cpu_online_map), which is not synchronizing against anything.
> >
> > Keep the other smp_wmb(), before the cpumask_set_cp
Hi Stefano,
On 07/12/2016 19:02, Stefano Stabellini wrote:
Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
&cpu_online_map), which is not synchronizing against anything.
Keep the other smp_wmb(), before the cpumask_set_cpu call, to ensure
that all writes before setting the cpu onl
Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
&cpu_online_map), which is not synchronizing against anything.
Keep the other smp_wmb(), before the cpumask_set_cpu call, to ensure
that all writes before setting the cpu online are visible to other cpus.
For that to work properly, we n
On 07/12/2016 18:44, Stefano Stabellini wrote:
On Wed, 7 Dec 2016, Julien Grall wrote:
Andrew thinks that (on x86) there is actually nothing that CPU0 will be
looking at, that has been set by CPU1. However looking at the code it is
difficult to verify. There are many cpu notifiers and many thin
Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
&cpu_online_map), which is not synchronizing against anything.
Keep the other smp_wmb(), before the cpumask_set_cpu call, to ensure
that all writes before setting the cpu online are visible to other cpus.
For that to work properly, we n
On 12/07/16 05:43, Jan Beulich wrote:
On 07.12.16 at 02:07, wrote:
>> On 07/12/2016 01:00, Jiandi An wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -762,6 +762,8 @@ static int xenmem_add_to_physmap_batch(struct domain *d,
>>> rc = xenmem_add_to_physmap_one(
On Wed, 7 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 06/12/2016 20:32, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Stefano Stabellini wrote:
> > > On Tue, 6 Dec 2016, Andrew Cooper wrote:
> > > > On 05/12/2016 19:17, Stefano Stabellini wrote:
> > > > > On Mon, 5 Dec 2016, Andrew Coop
On Tue, 2016-12-06 at 13:48 +, Julien Grall wrote:
> === big.LITTLE ===
>
> Anastassios:interested in knowing the status of big.LITTLE
> support in Xen
> Dario: went through the thread on the ML. The consensus
> seems to be
> based on vcpu pin/affinity.
> Anastassi
Hi Stefano,
On 06/12/2016 20:32, Stefano Stabellini wrote:
On Tue, 6 Dec 2016, Stefano Stabellini wrote:
On Tue, 6 Dec 2016, Andrew Cooper wrote:
On 05/12/2016 19:17, Stefano Stabellini wrote:
On Mon, 5 Dec 2016, Andrew Cooper wrote:
None of these barriers serve any purpose, as they are not
% Heterogeneous Multi Processing Support in Xen
% Revision 1
\clearpage
# Basics
Status: **Design Document**
Architecture(s): x86, arm
Component(s): Hypervisor and toolstack
# Overview
HMP (Hetero
On Wed, Dec 07, 2016 at 09:34:30AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 07, 2016 at 12:26:19PM +0100, Daniel Kiper wrote:
> > On Tue, Dec 06, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On December 6, 2016 5:52:48 PM EST, Daniel Kiper
> > > wrote:
> > > >Hi,
> > > >
On Wed, Dec 07, 2016 at 09:33:55AM -0500, Konrad Rzeszutek Wilk wrote:
> ..snip..
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -528,6 +528,66 @@ The physical address to which the boot loader should
> > jump in order to
> > start running the operating system.
> > @end table
>
On Wed, Dec 07, 2016 at 06:43:40AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 23:25, wrote:
> > Current early command line parser implementation in assembler
> > is very difficult to change to relocatable stuff using segment
> > registers. This requires a lot of changes in very weird and
> > f
On Wed, Dec 07, 2016 at 06:18:19AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 23:25, wrote:
> > ..nor EFI platforms with runtime services enabled.
>
> Btw, was the title meant to read "... neither on non-EFI platforms ..."?
Right, thanks for pointing this out.
Daniel
___
Juergen Gross writes ("Xenstore domains and XS_RESTRICT"):
> In order to solve the problem I suggest the following change to the
> Xenstore wire protocol:
>
> struct xsd_sockmsg
> {
> -uint32_t type; /* XS_??? */
> +uint16_t type; /* XS_??? */
> +uint16_t domid; /* Use privileges o
On 07/12/16 11:43, Jan Beulich wrote:
On 07.12.16 at 02:07, wrote:
>> On 07/12/2016 01:00, Jiandi An wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -762,6 +762,8 @@ static int xenmem_add_to_physmap_batch(struct domain *d,
>>> rc = xenmem_add_to_physmap_one(
On 12/7/2016 8:51 AM, Jan Beulich wrote:
On 07.12.16 at 16:57, wrote:
I did the the following:
wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz
tar -xvzf xen-4.8.0.tar.gz
cd /usr/local/src/xen-4.8.0
./configure
The config.log is available at: http://napadata.net/paste/
Konrad Rzeszutek Wilk writes ("Re: Xenstore domains and XS_RESTRICT"):
> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
> > There is no socket connection to xenstore domain.
>
> Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
> with domid_id of zero? Or are
Am 07.12.2016 um 17:38 schrieb Samuel Thibault:
> Hello,
>
> Jan Beulich, on Wed 07 Dec 2016 09:28:52 -0700, wrote:
>>> Right. Jan, could you please include the patch for 4.7.2? Upstream
>>> commit was 9714f6b87e19b32d3a6663a20df6610265c4bfe5.
>>
>> Samuel, could you confirm that this is okay to b
Wei Liu writes ("Re: [PATCH] misc/release-checklist: Import from
xenbits:~xen/release-checklist"):
> On Mon, Dec 05, 2016 at 12:36:12PM +, Ian Jackson wrote:
> > Please argue about the filename :-).
>
> I don't have opinion on this.
Thanks all :-). Committed.
Ian.
>>> On 07.12.16 at 16:57, wrote:
> I did the the following:
>
> wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz
> tar -xvzf xen-4.8.0.tar.gz
> cd /usr/local/src/xen-4.8.0
> ./configure
>
> The config.log is available at: http://napadata.net/paste/view/9e7faf3d
>
>
>
Am 07.12.2016 um 17:33 schrieb Jan Beulich:
On 07.12.16 at 17:10, wrote:
>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>>> On 28/09/16 01:33, Sven Köhler wrote:
Am 27.09.2016 um 14:52 schrieb Juergen Gross:
> On 27/09/16 14:09, Sven Köhler wrote:
>> Am 27.09.2016 um 14:02 schr
Hello,
Jan Beulich, on Wed 07 Dec 2016 09:28:52 -0700, wrote:
> > Right. Jan, could you please include the patch for 4.7.2? Upstream
> > commit was 9714f6b87e19b32d3a6663a20df6610265c4bfe5.
>
> Samuel, could you confirm that this is okay to backport.
For 4.7, yes.
> In which case the question t
>>> On 07.12.16 at 17:10, wrote:
> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>> On 28/09/16 01:33, Sven Köhler wrote:
>>> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
On 27/09/16 14:09, Sven Köhler wrote:
> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>> On 27/09/16 13:13, Sven
>>> On 07.12.16 at 17:08, wrote:
> On 07/12/16 15:47, Jan Beulich wrote:
> On 07.12.16 at 16:43, wrote:
>> On 07.12.16 at 16:38, wrote:
On 07/12/16 14:07, Jan Beulich wrote:
> By putting it after all instruction fetching has been done, we can both
> simplify the existing han
>>> On 07.12.16 at 17:18, wrote:
> On 07/12/16 17:10, Sven Köhler wrote:
>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>>> On 28/09/16 01:33, Sven Köhler wrote:
Am 27.09.2016 um 14:52 schrieb Juergen Gross:
> On 27/09/16 14:09, Sven Köhler wrote:
>> Am 27.09.2016 um 14:02 schrieb J
Matthew Allen writes ("Re: [Xen-devel] Possible improvement to Xen Security
Response Process"):
> I agree; I'm suggesting changes to the dates that the security team
> would propose to a discoverer.
Right.
Personally I think that batching would be valuable, if it does not
lead to either inordina
>>> On 07.12.16 at 16:54, wrote:
> On 07/12/16 14:09, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2670,51 +2670,40 @@ x86_emulate(
>> break;
>>
>> case 0x06: /* push %%es */
>> -src.val = x86_seg_
On 07/12/16 17:10, Sven Köhler wrote:
> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>> On 28/09/16 01:33, Sven Köhler wrote:
>>> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
On 27/09/16 14:09, Sven Köhler wrote:
> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>> On 27/09/16 13:13, S
Am 28.09.2016 um 05:50 schrieb Juergen Gross:
> On 28/09/16 01:33, Sven Köhler wrote:
>> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
>>> On 27/09/16 14:09, Sven Köhler wrote:
Am 27.09.2016 um 14:02 schrieb Juergen Gross:
> On 27/09/16 13:13, Sven Köhler wrote:
>> Am 27.09.2016 um 07:
On 07/12/16 15:47, Jan Beulich wrote:
On 07.12.16 at 16:43, wrote:
> On 07.12.16 at 16:38, wrote:
>>> On 07/12/16 14:07, Jan Beulich wrote:
By putting it after all instruction fetching has been done, we can both
simplify the existing handling of immediate operands and take care
On 07/12/16 15:39, Jan Beulich wrote:
On 07.12.16 at 16:31, wrote:
>> On 12/07/2016 10:14 AM, Jan Beulich wrote:
>> On 07.12.16 at 16:10, wrote:
On 12/07/2016 06:29 AM, Jan Beulich wrote:
On 06.12.16 at 17:23, wrote:
>> On 12/06/2016 06:44 AM, Jan Beulich wrote:
>>
>>> On 05.12.16 at 16:04, wrote:
> At the moment this flag is unconditionally set for PVHv2 domains. Note that
> using this boot flag requires that the FADT table revision is at least 5 (or
> any
> later version), so bump the current FADT version from 4 to 5 and add two new
> fields that will be
>>> On 05.12.16 at 16:04, wrote:
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -949,7 +949,7 @@ void hvmloader_acpi_build_tables(struct acpi_config
> *config,
> config->table_flags |= ACPI_HAS_SSDT_S4;
>
> config->table_flags |= (ACPI_HAS_TCP
flight 103027 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103027/
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 1
flight 102998 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102998/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 102940
test-armhf-armh
I did the the following:
wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz
tar -xvzf xen-4.8.0.tar.gz
cd /usr/local/src/xen-4.8.0
./configure
The config.log is available at: http://napadata.net/paste/view/9e7faf3d
make
...
mv -f .efi.lds.d.new .efi.lds.d
gcc
On 07/12/16 16:40, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
>> On 07/12/16 15:15, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote:
Hi,
today the XS_RESTRICT wire command of Xenstore is
On 07/12/16 14:09, Jan Beulich wrote:
> Now that segment registers are numbered naturally this can be easily
> done to achieve some code size reduction.
>
> Also consistently use X86EMUL_OKAY in the code being touched.
>
> Signed-off-by: Jan Beulich
Nice improvement in principle, but...
>
> ---
>>> On 07.12.16 at 16:43, wrote:
On 07.12.16 at 16:38, wrote:
>> On 07/12/16 14:07, Jan Beulich wrote:
>>> By putting it after all instruction fetching has been done, we can both
>>> simplify the existing handling of immediate operands and take care of
>>> any future instructions allowing rI
>>> On 07.12.16 at 16:38, wrote:
> On 07/12/16 14:07, Jan Beulich wrote:
>> By putting it after all instruction fetching has been done, we can both
>> simplify the existing handling of immediate operands and take care of
>> any future instructions allowing rIP-relative operands and getting
>> addi
On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
> On 07/12/16 15:15, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote:
> >> Hi,
> >>
> >> today the XS_RESTRICT wire command of Xenstore is supported by
> >> oxenstored only to drop the priv
>>> On 07.12.16 at 16:31, wrote:
> On 12/07/2016 10:14 AM, Jan Beulich wrote:
> On 07.12.16 at 16:10, wrote:
>>> On 12/07/2016 06:29 AM, Jan Beulich wrote:
>>> On 06.12.16 at 17:23, wrote:
> On 12/06/2016 06:44 AM, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen
On 07/12/16 14:07, Jan Beulich wrote:
> By putting it after all instruction fetching has been done, we can both
> simplify the existing handling of immediate operands and take care of
> any future instructions allowing rIP-relative operands and getting
> additional bytes fetched in x86_decode_*() (
On 07/12/16 14:05, Jan Beulich wrote:
> Commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") can be had with
> less code: Simply do the destination register override depending on
> DstEax being in effect (the four other ModRM.reg encoded operations of
> these two opcodes all use DstMem).
>
> Sign
>>> On 07.12.16 at 16:16, wrote:
> On 06/12/16 14:14, Jan Beulich wrote:
>> The memory clobber is rather harsh here.
>
> Does removing it actually make a difference? I can't spot anything
> which could reasonably be reordered around the asm() blocks.
It's not so much the re-ordering but the pot
On 07/12/16 14:03, Jan Beulich wrote:
> ->read is required to be non-NULL, and is not being checked anywhere else.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-d
On 07/12/16 14:02, Jan Beulich wrote:
> There's no point reading CS - all of the fields get set from scratch
> right afterwards. Also correct a wrong comment.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x8
On 12/07/2016 10:14 AM, Jan Beulich wrote:
On 07.12.16 at 16:10, wrote:
>> On 12/07/2016 06:29 AM, Jan Beulich wrote:
>> On 06.12.16 at 17:23, wrote:
On 12/06/2016 06:44 AM, Jan Beulich wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -154,6 +154,13
alexander.le...@verizon.com writes ("RE: megaraid_sas regression in linux-3.18
[and 1 more messages]"):
> On Fri, Dec 02, 2016 at 02:36:22PM +, Ian Jackson wrote:
> > Stable maintainers, could you please incorporate 5e5ec1759dd6 into
> > linux-3.18.y ?
>
> Added 5e5ec1759dd6 to the 3.18 queue
On 07/12/16 15:16, Jan Beulich wrote:
On 07.12.16 at 16:06, wrote:
>> On 06/12/16 14:13, Jan Beulich wrote:
>>> @@ -3670,6 +3652,7 @@ x86_emulate(
>>>
>>> case 0xd8: /* FPU 0xd8 */
>>> host_and_vcpu_must_have(fpu);
>>> +get_fpu(X86EMUL_FPU_fpu, &fic);
>>> swit
On 07/12/16 15:10, Wei Liu wrote:
> Now it is controlled by Kconfig.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 06/12/16 14:14, Jan Beulich wrote:
> The memory clobber is rather harsh here.
Does removing it actually make a difference? I can't spot anything
which could reasonably be reordered around the asm() blocks.
> However, fic.exn_raised may be
> modified as a side effect, so we need to let the com
>>> On 07.12.16 at 16:06, wrote:
> On 06/12/16 14:13, Jan Beulich wrote:
>> @@ -3670,6 +3652,7 @@ x86_emulate(
>>
>> case 0xd8: /* FPU 0xd8 */
>> host_and_vcpu_must_have(fpu);
>> +get_fpu(X86EMUL_FPU_fpu, &fic);
>> switch ( modrm )
>> {
>> case 0x
When a 32-bit address override is in effect these zero-extend all
registers which would also get updated in case of non-zero repeat
count.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -933,15 +
On 12/07/2016 06:29 AM, Jan Beulich wrote:
On 06.12.16 at 17:23, wrote:
>> On 12/06/2016 06:44 AM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -154,6 +154,13 @@ static void __init calculate_hvm_feature
>>> __set_bit(X86_FEATURE_APIC, hvm_featur
Rename _get_rep_prefix() to make it more visibly fit other use cases
and introduce a companion "put". Use them for repeated string insn
handling as well as LOOP/J?CXZ instead of open coding the same logic a
couple of times.
Signed-off-by: Jan Beulich
---
v2: s/int_regs/regs/ in {get,put}_loop_cou
1 - 100 of 165 matches
Mail list logo
