On Tue, Jan 24, 2017 at 04:37:27PM -0600, Eric DeVolder wrote:
> On 01/24/2017 01:16 PM, Daniel Kiper wrote:
> >On Tue, Jan 24, 2017 at 12:55:35PM -0600, Eric DeVolder wrote:
[...]
> >>diff --git a/configure.ac b/configure.ac
> >>index 3044185..c6e864b 100644
> >>--- a/configure.ac
> >>+++ b/conf
On Tue, Jan 24, 2017 at 04:47:09PM -0600, Eric DeVolder wrote:
> On 01/24/2017 01:16 PM, Daniel Kiper wrote:
> >On Tue, Jan 24, 2017 at 12:55:35PM -0600, Eric DeVolder wrote:
[...]
> >>diff --git a/kexec/kexec.c b/kexec/kexec.c
> >>index 500e5a9..defbbe3 100644
> >>--- a/kexec/kexec.c
> >>+++ b/k
On 01/25/2017 01:05 AM, Stefano Stabellini wrote:
On Tue, 24 Jan 2017, Oleksandr Andrushchenko wrote:
On 01/23/2017 09:49 PM, Stefano Stabellini wrote:
On Sat, 21 Jan 2017, Oleksandr Andrushchenko wrote:
In the mail-thread you mentioned above there is a picture of
the xenstore entries and conc
>>> On 24.01.17 at 17:33, wrote:
>> On Jan 24, 2017, at 3:08 PM, Jan Beulich wrote:
> On 24.01.17 at 16:01, wrote:
On Jan 24, 2017, at 11:43 AM, Jan Beulich wrote:
>>> On 24.01.17 at 12:33, wrote:
> Jan Beulich writes ("Re: [Xen-devel] RFC: Adding a section to the Xen
>>> sec
flight 104636 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104636/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104617
test-armhf-armhf-libvirt 13
>>> On 24.01.17 at 17:30, wrote:
> The entirety of edx is reserved.
>
> Intel only defines the lower 16 bits of eax, although ebx is covered by the
> featureset ABI, so left unclobbered.
>
> AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
> guest maxphysaddr to HVM
>>> On 24.01.17 at 17:31, wrote:
> Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf
> 0x801a is performance hints. These leaves have previously been hidden
> from guests, but are perfectly safe to expose when appicable.
>
> Update libxc to also expose these leav
This run is configured for baseline tests only.
flight 68451 linux-3.10 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68451/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 2 hosts-allocate
On Tue, Jan 24, 2017 at 07:27:36PM +, Andrew Cooper wrote:
> On 20/01/17 12:11, Wei Liu wrote:
> > And rename README to README.oss-fuzz.
> >
> > Signed-off-by: Wei Liu
> > ---
> > Cc: Andrew Cooper
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Jan Beulich
> > ---
> > tools/fuzz/README
On Tue, Jan 24, 2017 at 7:27 PM, Andrew Cooper
wrote:
> On 20/01/17 12:11, Wei Liu wrote:
>> And rename README to README.oss-fuzz.
>>
>> Signed-off-by: Wei Liu
>> ---
>> Cc: Andrew Cooper
>> Cc: George Dunlap
>> Cc: Ian Jackson
>> Cc: Jan Beulich
>> ---
>> tools/fuzz/README.afl
On Wed, Jan 25, 2017 at 09:51:38AM +, George Dunlap wrote:
> On Tue, Jan 24, 2017 at 7:27 PM, Andrew Cooper
> wrote:
> > On 20/01/17 12:11, Wei Liu wrote:
> >> And rename README to README.oss-fuzz.
> >>
> >> Signed-off-by: Wei Liu
> >> ---
> >> Cc: Andrew Cooper
> >> Cc: George Dunlap
> >>
Hello Tamas,
On 25/01/2017 00:16, Tamas K Lengyel wrote:
The change in commit 438c5fe4f0c introduced a regression for domains where
mem_acces is or was active. When relinquish_p2m_mapping attempts to clear
a page where the order is not 0 the following ASSERT is triggered:
ASSERT(!p2m->mem_a
1: x86emul: correct VEX/XOP/EVEX operand size handling for 16-bit code
2: x86/emulate: don't assume that addr_size == 32 implies protected mode
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-dev
Operand size defaults to 32 bits in that case, but would not have been
set that way in the absence of an operand size override.
Reported-by: Wei Liu
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2298,6 +2298,11 @@ x86_de
From: George Dunlap
Callers of x86_emulate() generally define addr_size based on the code
segment. In vm86 mode, the code segment is set by the hardware to be
16-bits; but it is entirely possible to enable protected mode, set the
CS to 32-bits, and then disable protected mode. (This is commonly
On 25/01/17 10:31, Jan Beulich wrote:
> Operand size defaults to 32 bits in that case, but would not have been
> set that way in the absence of an operand size override.
>
> Reported-by: Wei Liu
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Possibly worth mentioning that it was found
On 25/01/17 10:32, Jan Beulich wrote:
> From: George Dunlap
>
> Callers of x86_emulate() generally define addr_size based on the code
> segment. In vm86 mode, the code segment is set by the hardware to be
> 16-bits; but it is entirely possible to enable protected mode, set the
> CS to 32-bits, an
In 58cbc034 send_irq permission was removed but there was still
reference to it in policy file. Remove the stale reference.
And now we also need dm permission. Add that.
Signed-off-by: Wei Liu
---
Cc: Daniel De Graaf
Cc: Paul Durrant
Cc: Ian Jackson
Staging is currently broken.
---
tools/fl
The documentation states that a value of '1' will cause unplug of
emulated IDE disks. This is not quite correct, as QEMU will also unplug
emulated SCSI disks at the same time.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszu
flight 104641 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104641/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc
baseline version:
xen e225
On Wed, Jan 25, 2017 at 10:42:55AM +, Paul Durrant wrote:
> The documentation states that a value of '1' will cause unplug of
> emulated IDE disks. This is not quite correct, as QEMU will also unplug
> emulated SCSI disks at the same time.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 25 January 2017 10:43
> To: Xen-devel
> Cc: Wei Liu ; Daniel De Graaf
> ; Paul Durrant ; Ian
> Jackson
> Subject: [PATCH] flask: fix build after the introduction of DMOP
>
> In 58cbc034 send_irq permission was remo
flight 104642 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 104630
build-armhf
On Tue, Jan 24, 2017 at 01:30:02PM -0800, Stefano Stabellini wrote:
> On Tue, 24 Jan 2017, Stefano Stabellini wrote:
> > On Tue, 24 Jan 2017, Roger Pau Monné wrote:
> > > Hello,
> > >
> > > The following commit:
> > >
> > > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
> > > Author: Juergen Gro
On Tue, 2017-01-24 at 15:06 +, Julien Grall wrote:
> On 24/01/17 14:16, Dario Faggioli wrote:
> > There, we have tracing (BTW, did that made it to ARM eventually?)
> > and
> > there's TRC_PM_IDLE_ENTRY/EXIT which do pretty much the same of
> > your
> > printk-s.
>
> There is patch on the ML fo
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 24 January 2017 23:49
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Stefano
> Stabellini ; Anthony Perard
> ; Michael S. Tsirkin ; Paolo
> Bonzini ; Richard Henderson ;
Coverity-ID: 1399557
Signed-off-by: Wei Liu
---
tools/fuzz/libelf/libelf-fuzzer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/fuzz/libelf/libelf-fuzzer.c
b/tools/fuzz/libelf/libelf-fuzzer.c
index 71561d3460..1ba8571711 100644
--- a/tools/fuzz/libelf/libelf-fuzze
Prompted by coverity scan.
Wei Liu (2):
fuzz/libelf: return early if elf_init fails
fuzz/libelf: exit with fuzzer function return value
tools/fuzz/libelf/afl-libelf-fuzzer.c | 4 +---
tools/fuzz/libelf/libelf-fuzzer.c | 4 +++-
2 files changed, 4 insertions(+), 4 deletions(-)
--
2.11.0
Now the function can return nonzero value. Use that value as exit code
for the stub program. AFL might be able to use such information to
optimise fuzzing process.
Signed-off-by: Wei Liu
---
tools/fuzz/libelf/afl-libelf-fuzzer.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --gi
On Tue, Jan 24, 2017 at 12:07:16PM -0800, Stefano Stabellini wrote:
> On Tue, 24 Jan 2017, Julien Grall wrote:
> > > > ## Discovering and register hostbridge
> > > >
> > > > Both ACPI and Device Tree do not provide enough information to fully
> > > > instantiate an host bridge driver. In the case
flight 104639 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104639/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 26ca6f7e1e2f3ba247d1d3150d6bfb22043a8cda
baseline version:
ovmf 9d77acf1566fae033ae2d
On Tue, Jan 24, 2017 at 05:17:06PM +, Julien Grall wrote:
> Hi Roger,
>
> On 06/01/17 15:12, Roger Pau Monné wrote:
> > On Thu, Dec 29, 2016 at 02:04:15PM +, Julien Grall wrote:
> > > So given a specific SBDF, it would be possible to find the host bridge
> > > and the
> > > RID associated
This run is configured for baseline tests only.
flight 68463 xen-4.0-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68463/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-i386-i386-xl 1 build-check(
Hi Dario,
On 25/01/17 11:10, Dario Faggioli wrote:
On Tue, 2017-01-24 at 15:06 +, Julien Grall wrote:
On 24/01/17 14:16, Dario Faggioli wrote:
There, we have tracing (BTW, did that made it to ARM eventually?)
and
there's TRC_PM_IDLE_ENTRY/EXIT which do pretty much the same of
your
printk-s
On 25/01/17 12:38, Julien Grall wrote:
> Hi Dario,
>
> On 25/01/17 11:10, Dario Faggioli wrote:
>> On Tue, 2017-01-24 at 15:06 +, Julien Grall wrote:
>>> On 24/01/17 14:16, Dario Faggioli wrote:
There, we have tracing (BTW, did that made it to ARM eventually?)
and
there's TRC_PM_
flight 104637 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104637/
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. 59254
test-armhf-armhf-xl
On Tue, 2017-01-24 at 16:03 -0700, Jim Fehlig wrote:
> On 01/20/2017 09:06 AM, Juergen Gross wrote:
> > On 20/01/17 16:54, Ian Jackson wrote:
> > > Juergen Gross writes ("memory hotplug for domUs"):
> > > > We first thought to enhance "xl mem-set", but after some more
> > > > thinking
> > > > about
flight 104644 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 104630
build-armhf
Recent additions to xlat.lst have apparently resulted in Python's
garbage collection getting in the way: I would guess that so far it
managed to re-use previously compiled regular expressions, but with the
higher number of them now can't anymore (at least with default
settings). Do the compilation
On 25/01/17 13:43, Jan Beulich wrote:
> Recent additions to xlat.lst have apparently resulted in Python's
> garbage collection getting in the way: I would guess that so far it
> managed to re-use previously compiled regular expressions, but with the
> higher number of them now can't anymore (at lea
> x86: enforce consistent cachability of MMIO mappings
>
> We've been told by Intel that inconsistent cachability between
> multiple mappings of the same page can affect system stability only
> when the affected page is an MMIO one. Since the stale data issue is
> of no relevance to the hypervisor
flight 104647 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104647/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 104630
build-armhf
>>> On 25.01.17 at 15:08, wrote:
>> --- a/xen/arch/x86/hvm/mtrr.c
>> +++ b/xen/arch/x86/hvm/mtrr.c
>> @@ -770,8 +770,17 @@ int epte_get_entry_emt(struct domain *d,
>> if ( v->domain != d )
>> v = d->vcpu ? d->vcpu[0] : NULL;
>>
>> -if ( !mfn_valid(mfn_x(mfn)) )
>> +if ( !mf
On 25/01/17 12:40, Andrew Cooper wrote:
On 25/01/17 12:38, Julien Grall wrote:
Hi Dario,
On 25/01/17 11:10, Dario Faggioli wrote:
On Tue, 2017-01-24 at 15:06 +, Julien Grall wrote:
On 24/01/17 14:16, Dario Faggioli wrote:
There, we have tracing (BTW, did that made it to ARM eventually?
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Daniel De Graaf
CC: Paul Durrant
CC: Ian Jackson
Might be better to merge into one single patch when committed?
---
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/x
On Mon, Nov 28, 2016 at 10:14:00AM -0800, Stefano Stabellini wrote:
> On Fri, 25 Nov 2016, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
>
> Acked-by: Stefano Stabellini
Hi,
This patch has never been applied.
Thanks,
> > MAINTAINERS | 2 +-
> > 1 file changed, 1 insertion(+), 1 de
On 25/01/17 14:29, Anthony PERARD wrote:
> On Mon, Nov 28, 2016 at 10:14:00AM -0800, Stefano Stabellini wrote:
>> On Fri, 25 Nov 2016, Anthony PERARD wrote:
>>> Signed-off-by: Anthony PERARD
>> Acked-by: Stefano Stabellini
> Hi,
>
> This patch has never been applied.
Queued. Sorry for letting i
On Wed, 2017-01-25 at 07:21 -0700, Jan Beulich wrote:
> Note the difference between "contains" and "overlaps".
Oh, that makes more sense; thanks.
> > And then there's a 'if (direct_mmio) return UC;' further down which
> > looks like it'd do the right thing for the use case I'm actually
> > testin
On 25/01/17 14:32, Andrew Cooper wrote:
> On 25/01/17 14:29, Anthony PERARD wrote:
>> On Mon, Nov 28, 2016 at 10:14:00AM -0800, Stefano Stabellini wrote:
>>> On Fri, 25 Nov 2016, Anthony PERARD wrote:
Signed-off-by: Anthony PERARD
>>> Acked-by: Stefano Stabellini
>> Hi,
>>
>> This patch has
This includes support for AVX counterparts of them as well as a few
later SSE additions (basically covering the entire 0f-prefixed opcode
space, but not the 0f38 and 0f3a ones, nor 3dnow). This series is
still partly RFC, as I've still not worked out a good way of testing the
new additions - for no
Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
noteworthy exception of #PF) occur inside the stub, forward it to the
guest.
Since the exception fixup table entry can't encode the address of the
faulting insn it
This aims at covering most MMX/SSEn/AVX instructions in the 0x0f-escape
space with memory operands. Not covered here are irregular moves,
converts, and {,U}COMIS{S,D} (modifying EFLAGS).
Note that the distinction between simd_*_fp isn't strictly needed, but
I've kept them as separate entries since
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -253,9 +253,9 @@ static const struct {
[0x22 ... 0x23] = { DstImplicit|SrcMem|ModRM },
[0x28] = { DstImplicit|SrcMem|ModRM|Mov, simd_packed_fp },
[0x29] = { DstMe
Previously supported insns are being converted to the new model, and
several new ones are being added.
To keep the stub handling reasonably simple, integrate SET_SSE_PREFIX()
into copy_REX_VEX(), at once switching the stubs to use an empty REX
prefix instead of a double DS: one (no byte registers
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -256,7 +256,7 @@ static const struct {
[0x2a] = { DstImplicit|SrcMem|ModRM, simd_other },
[0x2b] = { DstMem|SrcImplicit|ModRM|Mov, simd_any_fp },
[0x2c ... 0x2d]
This involves fixing a decode bug: VEX encoded insns aren't necessarily
followed by a ModR/M byte.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -282,11 +282,11 @@ static const struct {
[0x6e] = { DstImplicit|SrcMem|M
Signed-off-by: Jan Beulich
--- a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
+++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
@@ -119,7 +119,7 @@ int LLVMFuzzerTestOneInput(const uint8_t
unsigned int x;
const uint8_t *p = data_p;
-stack_exec
> -Original Message-
> From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com]
> Sent: 19 January 2017 11:14
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk ; Wei Liu
> ; net...@vger.kernel.org; xen-
> de...@lists.xenproject.org
> Subject: Re: [Xen-devel] xennet_start_xmit assumptions
>
... as the only post-SSE2 move insn.
Signed-off-by: Jan Beulich
---
v2: Re-base.
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -2354,6 +2354,74 @@ int main(int argc, char **argv)
else
printf("skipped\n");
+printf("%-4
Hello Manish,
On 25/01/17 04:37, Manish Jaggi wrote:
On 01/24/2017 11:13 PM, Julien Grall wrote:
On 19/01/17 05:09, Manish Jaggi wrote:
I think, PCI passthrough and DOM0 w/ACPI enumerating devices on PCI are
separate features.
Without Xen mapping PCI config space region in stage2 of dom0, A
flight 104646 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104646/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2bdfb11df9ca0ea0a136e39baac3548b295732b9
baseline version:
ovmf 26ca6f7e1e2f3ba247d1d
Instead of the scripts having to poke at various fields we can
provide that functionality via the -S parameter.
kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash
state. It does not say anything about Xen kexec/crash state. So,
we need a special approach to get the latter. Though for
flight 104648 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104648/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 104630
build-armhf
Signed-off-by: Wei Liu
---
tools/tests/x86_emulator/test_x86_emulator.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/tests/x86_emulator/test_x86_emulator.c
b/tools/tests/x86_emulator/test_x86_emulator.c
index 924fd36f18..e86369ffe7 100644
--- a/tools/tests/x8
Signed-off-by: Wei Liu
---
tools/fuzz/README.afl | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/fuzz/README.afl b/tools/fuzz/README.afl
index 431b4a8cbf..68e0fa396f 100644
--- a/tools/fuzz/README.afl
+++ b/tools/fuzz/README.afl
@@ -20,9 +20,10 @@ Use the x86 instru
... so that they can be used by userspace x86 instruction emulator test
program and fuzzer as well.
No functional change.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/processor.h | 121 +-
xen/include/asm-x86/x86-defns.h | 125 ++
Wei Liu (7):
x86emul/test: remove extraneous commas in debug messages
x86_emulate: lift a bunch of macros to header file
x86: extract macros to x86-defns.h
x86emul/test: use x86-defns.h
fuzz/x86emul: update fuzzer
fuzz/x86emul: print out minimal input size
fuzz: update README.afl exam
Provide the fuzzer with more ops, and more sophisticated input
structure.
Based on a patch originally written by Andrew and George.
Signed-off-by: Andrew Cooper
Signed-off-by: George Dunlap
Signed-off-by: Wei Liu
---
.../x86-insn-emulator-fuzzer.c | 653 +++
Signed-off-by: Wei Liu
---
tools/tests/x86_emulator/x86_emulate.h | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tools/tests/x86_emulator/x86_emulate.h
b/tools/tests/x86_emulator/x86_emulate.h
index 3a6badee46..3a1d8ccad2 100644
--- a/tools/tests/x86_emulator/x86_emul
... so that users can know how big the initial input should be.
Signed-off-by: Wei Liu
---
.../fuzz/x86_instruction_emulator/afl-x86-insn-emulator-fuzzer.c | 8
tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c| 5 +
2 files changed, 13 insertions(+)
diff --git a/
Some of them can be shared between hypervisor and userspace fuzzing /
test code. Instead of lifting the ones as we need, lift them all.
And then remove the ones in test program.
Signed-off-by: Wei Liu
---
tools/tests/x86_emulator/test_x86_emulator.c | 9 ---
xen/arch/x86/x86_emulate/x86_emulat
On (01/25/17 15:06), Paul Durrant wrote:
>
> Making netfront cope with a fully non-linear skb looks like it would
> be quite intrusive and probably not worth it so I opted for just doing
> the ETH_HLEN pull-tail if necessary. Can you check it works for you?
I tested it, and it works fine, but n
On Wed, Jan 25, 2017 at 02:24:28PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Daniel De Graaf
> CC: Paul Durrant
> CC: Ian Jackson
>
> Might be better to merge into one single patch when committed?
Yes, we should squash the two patches (the other
On Wed, 2017-01-25 at 12:38 +, Julien Grall wrote:
> Hi Dario,
>
Hey,
> On 25/01/17 11:10, Dario Faggioli wrote:
> > My point was that, still from scheduling perspective, neither
> > Credit1
> > nor Credit2 sets a wakeup timer for idle pCPUs.
> >
> > Well, in Credit1, the master_ticker timer
On Wed, 2017-01-25 at 07:21 -0700, Jan Beulich wrote:
>
> If there wasn't INVALID_MFN to be taken care of, the !mfn_valid()
> check could simply move down, and be combined with the
> direct_mmio one.
As discussed on IRC, once we fix the overflow with order > 0, I think
INVALID_MFN is OK. Not that
The change in commit 438c5fe4f0c introduced a regression for domains where
mem_acces is or was active. When relinquish_p2m_mapping attempts to clear
a page where the order is not 0 the following ASSERT is triggered:
ASSERT(!p2m->mem_access_enabled || page_order == 0);
This regression was unfo
Sowmini points out two vulnerabilities in xen-netfront:
a) The code assumes that skb->len is at least ETH_HLEN.
b) The code assumes that at least ETH_HLEN octets are in the linear
port of the socket buffer.
This patch adds tests for both of these, and in the case of the latter
pulls sufficient
>>> On 25.01.17 at 16:44, wrote:
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -42,7 +42,7 @@ static int read(
> struct x86_emulate_ctxt *ctxt)
> {
> if ( verbose )
> -printf("** %s(%u, %p,, %u,)\n", __func__, seg,
On Wed, Jan 25, 2017 at 09:33:05AM -0700, Jan Beulich wrote:
> >>> On 25.01.17 at 16:44, wrote:
> > --- a/tools/tests/x86_emulator/test_x86_emulator.c
> > +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> > @@ -42,7 +42,7 @@ static int read(
> > struct x86_emulate_ctxt *ctxt)
> > {
> >
On Wed, 2017-01-25 at 16:26 +, Paul Durrant wrote:
> Sowmini points out two vulnerabilities in xen-netfront:
>
> a) The code assumes that skb->len is at least ETH_HLEN.
> b) The code assumes that at least ETH_HLEN octets are in the linear
>port of the socket buffer.
>
> This patch adds te
flight 104649 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 104630
build-armhf
Move the actual execution of `iptable' into a new function which
captures the stderr, and logs it. The actual `iptables' command is a
parameter to `frob_iptable_command' so that in future we can reuse
this subroutine for `ip6tables'.
No functional change other than to log messages.
Signed-off-by
Break frob_iptable into two subroutines frob_iptable_in and
frob_iptable_out_all.
frob_iptable_in must be called with the iptables command name and
appropriate parameters (for each source address or condition, as
necessary).
frob_iptable_out_all must be called exactly once.
Signed-off-by: Ian Ja
On Mon, Jan 23, 2017 at 11:43:30AM -0500, Ronald Rojas wrote:
[...]
> +
> +subdir-distclean-firmware: .phony
> + $(MAKE) -C firmware distclean
> +
This looks unrelated.
> subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
> $(MAKE) -C debugger/gdbsx clean
>
> diff --
Sylvain Munaut writes ("Re: [PATCH 3/5] hotplug/linux: Improve iptables logic"):
> And just moving the 'out' rule outside of frob_iptables alltogether
> seems hackish to me, especially when you add IPv6 later on because you
> have iptables manipulations spread around.
Sorry for the terseness of my
On Thu, Jan 05, 2017 at 04:54:37PM -0800, Stefano Stabellini wrote:
> Changes in v3:
> - clarify a few statements
> - rename port- to event-channel-
> - use grant_ref_t ref[1] instead of ref[]
>
> Changes in v2:
> - fix copy/paste error
> - rename ring-ref- to ring-ref
> - fix memory barriers
> -
flight 104638 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 4 host-build-prep fail REGR. vs. 104614
Tests which are fa
flight 104651 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 104630
build-armhf
On Mon, Jan 23, 2017 at 4:43 PM, Ronald Rojas wrote:
> +func (Ctx *Context) Open() (err error) {
> + if Ctx.ctx != nil {
> + return
> + }
> +
> + ret := C.libxl_ctx_alloc(unsafe.Pointer(&Ctx.ctx), C.LIBXL_VERSION,
> 0, nil)
Just discovered there's a bug here (in
Currently there can be up to 256 entries in a guest's MSR array and all
entries are stored in the order they were added. Such design requires
to perform a linear scan of the whole array in order to find the MSR
with required index which can be a costly operation.
To avoid that, reuse the existing
The first patch is a general optimization which is nice to have prior
to the second patch which contains the real fix.
A similar bug was fixed in Linux's perf subsystem in Jun 2016:
commit 19fc9ddd61e059cc45464bdf6e8fa304bb94080f
("perf/x86/intel: Fix MSR_LAST_BRANCH_FROM_x bug when no TS
During VM entry, H/W will automatically load guest's MSRs from MSR-load
area in the same way as they would be written by WRMSR.
However, under the following conditions:
1. LBR (Last Branch Record) MSRs were placed in the MSR-load area
2. Address format of LBR includes TSX bits 61:62
3
This file defines an ABI shared between guest and hypervisor(s)
(KVM, Xen) and as such there should be an correspondent entry in
MAINTAINERS file. Notice that there's already a text notice at the
top of the header file, hence this commit simply enforces it more
explicitly and have both peers notice
Hey,
This small series presents support for vDSO for Xen domains.
PVCLOCK_TSC_STABLE_BIT can be set starting Xen 4.8 which is required for vdso
time related calls. In order to have it on, you need to have the hypervisor
clocksource be TSC e.g. with the following boot params "clocksource=tsc
tsc=st
Right now there is only a pvclock_pvti_cpu0_va() which is defined
on kvmclock since:
commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
The only user of this interface was kvm. This commit moves
pvclock_pvti_cpu0_va to pvclock which is a more generic place
In order to support pvclock vdso on xen we need to setup the time
info page for vcpu 0 and register the page with Xen using the
VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
will also forcefully update the pvti which will set some of the
necessary flags for vdso. Afterwards we che
On Wed, 25 Jan 2017, Paul Durrant wrote:
> The documentation states that a value of '1' will cause unplug of
> emulated IDE disks. This is not quite correct, as QEMU will also unplug
> emulated SCSI disks at the same time.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Stefano Stabellini
> Cc:
On 25/01/17 16:36, Wei Liu wrote:
> On Wed, Jan 25, 2017 at 09:33:05AM -0700, Jan Beulich wrote:
> On 25.01.17 at 16:44, wrote:
>>> --- a/tools/tests/x86_emulator/test_x86_emulator.c
>>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
>>> @@ -42,7 +42,7 @@ static int read(
>>> struct x
On Wed, 25 Jan 2017, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 24 January 2017 23:49
> > To: Paul Durrant
> > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Stefano
> > Stabellini ; Anthony Perard
> > ; Mic
flight 104655 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104655/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 104630
build-armhf
1 - 100 of 164 matches
Mail list logo
