>>> On 06.12.16 at 17:37, wrote:
> On 12/06/2016 09:34 AM, Jan Beulich wrote:
> On 29.11.16 at 16:33, wrote:
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -651,6 +651,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>>> u_domctl)
>>> goto maxvcp
>>> On 06.12.16 at 16:56, wrote:
> On 06/12/16 13:25, Jan Beulich wrote:
>> Both need to raise #GP(0) when in VM86 mode with IOPL < 3.
>>
>> Additionally PUSHF is documented to clear VM and RF from the value
>> placed onto the stack.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/x86_e
>>> On 06.12.16 at 17:35, wrote:
> On 06/12/16 13:39, Jan Beulich wrote:
>> @@ -5424,7 +5436,6 @@ x86_emulate(
>> goto cannot_emulate;
>> }
>>
>> - writeback:
>
> This removal highlights that the writeback and no_writeback lables are
> incorrectly named.
>
> There intended meanin
>>> On 06.12.16 at 17:49, wrote:
> On 06/12/16 11:13, Jan Beulich wrote:
>> @@ -2359,7 +2360,7 @@ x86_decode(
>> }
>> }
>>
>> -if ( override_seg != -1 && ea.type == OP_MEM )
>> +if ( override_seg != x86_seg_none )
>> ea.mem.seg = override_seg;
>
> Could we get awa
>>> On 06.12.16 at 18:34, wrote:
> On 06/12/16 11:15, Jan Beulich wrote:
>> While the read and fetch hooks are basically unavoidable, write and
>> cmpxchg aren't really needed by that many insns.
>>
>> Signed-off-by: Jan Beulich
>
> As a corollary, please can we gain
>
> ASSERT(ops->read && ops
>>> On 06.12.16 at 20:14, wrote:
> On 06/12/16 11:16, Jan Beulich wrote:
>> @@ -2023,6 +2020,148 @@ static int read_gate_descriptor(unsigned
>> return 1;
>> }
>>
>> +struct priv_op_ctxt {
>> +struct x86_emulate_ctxt ctxt;
>> +struct {
>> +unsigned long base, limit;
>> +
>>> On 06.12.16 at 17:20, wrote:
> On 06/12/16 13:38, Jan Beulich wrote:
>> @@ -3977,33 +3981,21 @@ x86_emulate(
>> break;
>>
>> case 0xe0 ... 0xe2: /* loop{,z,nz} */ {
>> +unsigned long count = get_loop_count(&_regs, ad_bytes) - 1;
>> int do_jmp = !(_regs.eflags &
flight 103018 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103018/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen cb6ae256e844a954170b9d7d2b6fd1e6000bb50e
baseline version:
xen 8e4b
flight 103012 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103012/
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 at 17:35, wrote:
> On 06/12/16 13:39, Jan Beulich wrote:
>> @@ -5424,7 +5436,6 @@ x86_emulate(
>> goto cannot_emulate;
>> }
>>
>> - writeback:
>
> This removal highlights that the writeback and no_writeback lables are
> incorrectly named.
>
> There intended meanin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-9815,CVE-2016-9816,CVE-2016-9817,CVE-2016-9818
/ XSA-201
version 2
ARM guests may induce host asynchronous abort
UPDATES IN VERSION 2
CVEs assigned.
IS
On 06/12/16 13:17, Jan Beulich wrote:
On 06.12.16 at 12:56, wrote:
>> On 06/12/16 11:12, Jan Beulich wrote:
>>> +static int gate_op_read(
>>> +enum x86_segment seg,
>>> +unsigned long offset,
>>> +void *p_data,
>>> +unsigned int bytes,
>>> +struct x86_emulate_ctxt *ctxt)
>
On Mon, Nov 28, 2016 at 02:53:57PM +0100, Cédric Bosdonnat wrote:
> Resume is sometimes silently failing for HVM guests. Getting the
> xc_domain_resume() and libxl__domain_resume_device_model() in the
> reverse order than what is in the suspend code fixes the problem.
>
> Signed-off-by: Cédric Bos
>>> On 07.12.16 at 11:55, wrote:
> On 06/12/16 13:17, Jan Beulich wrote:
> On 06.12.16 at 12:56, wrote:
>>> On 06/12/16 11:12, Jan Beulich wrote:
+return X86EMUL_UNHANDLEABLE;
+
+if ( is_pv_32bit_vcpu(current) )
+addr = (uint32_t)addr;
>>> This should b
On Mon, Nov 14, 2016 at 03:57:00PM +0100, Cédric Bosdonnat wrote:
> Qdisk supports qcow and qcow2, extend it to also support qed disk
> format.
>
> Signed-off-by: Cédric Bosdonnat
> ---
> tools/libxl/libxl_device.c |1 +
> tools/libxl/libxl_dm.c |1 +
> tools/libxl/libxl_types.idl
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,
> >
> >This updated patch series adds description of the Multiboot2 protocol
> >new
> >features and fixes some issues found here and there.
> >
> >It applies t
>>> 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_featureset);
>>
>> /*
>> + * Xen can often p
On 07/12/16 11:23, Jan Beulich wrote:
On 07.12.16 at 11:55, wrote:
>> On 06/12/16 13:17, Jan Beulich wrote:
>> On 06.12.16 at 12:56, wrote:
On 06/12/16 11:12, Jan Beulich wrote:
> +return X86EMUL_UNHANDLEABLE;
> +
> +if ( is_pv_32bit_vcpu(current) )
> +
>>> 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(d, xatpb->space,
>>
On 07/12/16 09:56, Jan Beulich wrote:
On 06.12.16 at 17:20, wrote:
>> On 06/12/16 13:38, Jan Beulich wrote:
>>> @@ -3977,33 +3981,21 @@ x86_emulate(
>>> break;
>>>
>>> case 0xe0 ... 0xe2: /* loop{,z,nz} */ {
>>> +unsigned long count = get_loop_count(&_regs, ad_bytes) -
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 3ca45a4 "percpu: ensure requested alignment is power of two
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
---
xen/arch/arm/vgic-v3.c | 25 -
We will want to emulate co-processor registers access in a follow-up
patch.
Signed-off-by: Julien Grall
---
xen/arch/arm/vgic-v3.c | 13 -
xen/arch/arm/vgic.c| 4 ++--
xen/include/asm-arm/vgic.h | 4 ++--
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/x
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
---
xen/arch/arm/vtimer.c | 60 +--
xen/arch/arm/vtimer.h | 2 +-
2 files changed, 31 insertions(+), 31
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 with AArch32 guest except that
co-processor access to
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
---
xen/arch/arm/vtimer.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/vtimer.c b/xe
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
---
xen/arch/arm/vgic.c| 8
xen/include/asm-arm
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 required for AArch32
so nothing has to be changed th
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 bring much information
and can be misleading (
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
---
xen/arch/arm/Makefile | 2 +-
1 file changed, 1 insertion(+), 1
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
---
xen/arch/arm/vgic-v2.c | 4 ++--
xen/arch/arm/vgic-v3.c | 2 +-
xen/arch/arm/vgic.c| 8
xen/includ
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
---
The helpers will be necessary in a follow-up patch to emulate sysreg
for another components.
---
xen/arch/arm/vtimer.c |
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-bit
co-processor access are the same as the sysreg one.
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
---
xen/arch/arm/traps.c | 14 +++---
1 file changed, 7 i
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
---
xen/arch/arm/vgic-v3.c | 6 +++---
xen/arch/arm/vgic.c| 2 +-
xen/include/asm-arm/vgic.h | 4 ++--
3 files changed, 6 insertions(+)
>>> On 07.12.16 at 13:21, wrote:
> On 07/12/16 09:56, Jan Beulich wrote:
> On 06.12.16 at 17:20, wrote:
>>> On 06/12/16 13:38, Jan Beulich wrote:
@@ -3977,33 +3981,21 @@ x86_emulate(
break;
case 0xe0 ... 0xe2: /* loop{,z,nz} */ {
+unsigned long
On Wed, 2016-12-07 at 11:25 +, Wei Liu wrote:
> On Mon, Nov 14, 2016 at 03:57:00PM +0100, Cédric Bosdonnat wrote:
> > Qdisk supports qcow and qcow2, extend it to also support qed disk
> > format.
> >
> > Signed-off-by: Cédric Bosdonnat
> > ---
> > tools/libxl/libxl_device.c |1 +
> > to
On 07/12/16 08:22, Jan Beulich wrote:
On 06.12.16 at 17:49, wrote:
>> On 06/12/16 11:13, Jan Beulich wrote:
>>> @@ -2359,7 +2360,7 @@ x86_decode(
>>> }
>>> }
>>>
>>> -if ( override_seg != -1 && ea.type == OP_MEM )
>>> +if ( override_seg != x86_seg_none )
>>> e
>>> On 06.12.16 at 14:47, wrote:
> Today there is no way for a domain to obtain the number of entries of
> the machine memory map returned by XENMEM_machine_memory_map hypercall.
>
> Modify the interface to return just the needed number of map entries
> in case the buffer was specified as NULL.
>
>>> On 07.12.16 at 14:05, wrote:
> On 07/12/16 08:22, Jan Beulich wrote:
> On 06.12.16 at 17:49, wrote:
>>> On 06/12/16 11:13, Jan Beulich wrote:
@@ -2359,7 +2360,7 @@ x86_decode(
}
}
-if ( override_seg != -1 && ea.type == OP_MEM )
+if ( o
On 07/12/16 13:14, Jan Beulich wrote:
On 07.12.16 at 14:05, wrote:
>> On 07/12/16 08:22, Jan Beulich wrote:
>> On 06.12.16 at 17:49, wrote:
On 06/12/16 11:13, Jan Beulich wrote:
> @@ -2359,7 +2360,7 @@ x86_decode(
> }
> }
>
> -if ( override_se
>>> 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 ..."?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-winxpsp3
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-tradit
On 07/12/16 08:32, Jan Beulich wrote:
On 06.12.16 at 18:34, wrote:
>> On 06/12/16 11:15, Jan Beulich wrote:
>>> While the read and fetch hooks are basically unavoidable, write and
>>> cmpxchg aren't really needed by that many insns.
>>>
>>> Signed-off-by: Jan Beulich
>> As a corollary, pleas
>>> 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
> fragile code. So, reimplement this functionality in C. This
> way code w
>>> On 07.12.16 at 14:36, wrote:
> On 07/12/16 08:32, Jan Beulich wrote:
>> And I don't see why the ->cpuid() hook would be required all of the
>> sudden - all its uses are guarded by a NULL check.
>
> You made it convincing argument in c/s 043ad80 "x86: always supply
> .cpuid() handler to x86_em
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
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4841,12 +4841,10 @@ x86_emulate(
_regs.eflags &
->read is required to be non-NULL, and is not being checked anywhere else.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1686,8 +1686,6 @@ static int inject_swint(enum x86_swint_t
((ctxt->regs->eflags &
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).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_e
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_*() (the current cases of extra
bytes getting fetch
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
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2
On 07/12/16 14:05, Jan Beulich wrote:
On 06.12.16 at 14:47, wrote:
>> Today there is no way for a domain to obtain the number of entries of
>> the machine memory map returned by XENMEM_machine_memory_map hypercall.
>>
>> Modify the interface to return just the needed number of map entries
>>
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 privilege of a connection to that of the
> domid given as a parameter to the command.
>
> Using this mechanism with Xenstore runnin
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 privilege of a connection to that of the
>> domid given as a parameter to the c
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,
> > >
> > >This updated patch series adds description of the Multiboot2 protocol
> > >new
.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
>
> +@subsection EFI i386 entry address tag of Multiboot2 header
> +
> +@example
> +@g
On 06/12/16 14:11, Jan Beulich wrote:
> First of all there are a number of secondary encodings both Intel and
> AMD support, but which aren't formally documented.
Where did you get them from then?
(I'm fine with introducing these if they exist, but it would be good to
provide references if possib
1: consolidate loop counter handling
2: correct 64-bit mode repeated string insn handling with zero count
Signed-off-by: Jan Beulich
---
v2: Only patch 1 changed, see there.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-
On 06/12/16 14:12, Jan Beulich wrote:
> Consistently use ea instead of src for passing the memory address to
> ->read(). This eliminates the need to copy ea to src, resulting in a
> couple of hundred bytes smaller binary size.
>
> In addition for opcode DE we can leverage SrcMem16 to eliminate a ca
On 06/12/16 14:12, Jan Beulich wrote:
> Consolidate the copying of ea to dst: There's no need to set the type
> to OP_MEM, and instead the load cases setting it to OP_NONE allows the
> copying to be done just once per major opcode.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
>>> On 07.12.16 at 15:35, wrote:
> On 06/12/16 14:11, Jan Beulich wrote:
>> First of all there are a number of secondary encodings both Intel and
>> AMD support, but which aren't formally documented.
>
> Where did you get them from then?
>
> (I'm fine with introducing these if they exist, but it
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 0xc0 ... 0xc7: /* fadd %stN,%st */
> @@ -3715,
Now it is controlled by Kconfig.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
INSTALL | 3 ---
1 file changed, 3 deletions(-)
diff --git a/INSTALL b/INSTALL
On 06/12/16 14:13, Jan Beulich wrote:
> Accessing an 8-byte (or perhaps just 4-byte in the test harness when
> built as 32-bit app) field to read/write 10 bytes (leveraging the
> successive field) is a latent bug, as the compiler could copy things
> around. Use the 32 bytes large SSE/AVX slot inste
>>> 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 @@ static void __init calculate_hvm_feature
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
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
>>> 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
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 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 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
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 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
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 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: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: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 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 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: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 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 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 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
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
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
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
>>> 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
>>> 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 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:
>>
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 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
>>> 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_
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 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
>>> 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: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
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
1 - 100 of 165 matches
Mail list logo
