From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/kbdif.h | 210 ++
1 file changed, 210 insertions(+)
diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 446aed2478b5..74883267d6e6
From: Oleksandr Andrushchenko
Hi, all!
This series updates existing kbdif protocol documentation
and adds multi-touch support
Thank you,
Oleksandr Andrushchenko
Changes since v1:
* removed mtouch folder
* changed mtouch xenstore parameters' names
* single multi-touch device per driver, if m
From: Oleksandr Andrushchenko
Reviewed-by: Stefano Stabellini
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/kbdif.h | 248 +-
1 file changed, 221 insertions(+), 27 deletions(-)
diff --git a/xen/include/public/io/kbdif.h b/xen/include/
flight 104690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104690/
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
Qemu need this args to start userspace colo-proxy.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_dm.c | 104
tools/libxl/libxl_nic.c | 232
tools/libxl/libxl_types.idl | 31 +-
tools/libxl/xl_cmdimpl.c| 58 +++
Hi~ All~ Happy Chinese New Year~~
Because of some reason, We no longer support COLO kernel proxy.
So we send this patch set to make Xen use userspace colo-proxy in qemu.
Below is a COLO userspace proxy ascii figure:
Primary qemu
Secondar
Add remus '-p' to enable userspace colo proxy(in qemu).
Signed-off-by: Zhang Chen
---
docs/man/xl.pod.1.in | 4
tools/libxl/libxl_colo.h | 5 +
tools/libxl/libxl_colo_save.c | 2 ++
tools/libxl/libxl_types.idl | 17 +
tools/libxl/xl_cmdimpl.c | 13
In this patch we close kernel COLO-Proxy on primary side.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_colo_proxy.c | 30 ++
tools/libxl/libxl_colo_save.c | 9 +++--
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_colo_proxy.
In this patch we add a function to close
kernel COLO-Proxy on secondary side.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_colo_restore.c | 9 +++--
tools/libxl/libxl_create.c | 9 +++--
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 18 +++
We use old kernel colo proxy way to get the checkpoint event from qemu.
This patch have some TODO job.
Qemu compare need add a API to support this(I will add this in qemu).
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_colo.h | 2 ++
tools/libxl/libxl_colo_proxy.c | 12
too
Qemu need this args to start userspace colo-proxy.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_dm.c | 45 +++
tools/libxl/libxl_nic.c | 66 +
tools/libxl/libxl_types.idl | 15 ++-
tools/libxl/xl_cmdimpl.
This run is configured for baseline tests only.
flight 68460 qemu-upstream-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68460/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd
flight 104688 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104688/
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
flight 104662 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104662/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104643
test-amd64-amd64-xl-qemuu-
flight 104682 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104682/
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
flight 104654 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104654/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 4 host-build-prep fail in 104638 REGR. vs. 104614
Tests which are fa
flight 104679 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104679/
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
This run is configured for baseline tests only.
flight 68462 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68462/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5734d486b6aa0b69a39b2c8d52b355400bcf2551
jobs:
bu
flight 104676 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104676/
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
flight 104673 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104673/
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 Wed, 2017-01-18 at 03:30 -0700, Jan Beulich wrote:
> > > > On 18.01.17 at 11:21, wrote:
> > On 18/01/17 00:30, Dario Faggioli wrote:
> > > index ef8e0d8..d086264 100644
> > > --- a/xen/common/sched_credit2.c
> > > +++ b/xen/common/sched_credit2.c
> > > @@ -985,7 +985,7 @@ runq_tickle(const stru
In fact, it is quite useful a pice of information,
to know how long it is the "next time slice" a vCPU
has been granted. It allows one to assume (and then
check) when the scheduler is supposed to run next,
and other things.
While this information is indeed reported when a
context switch happens, i
When traversing a Credit2 runqueue to select the
best candidate vCPU to be run next, show in the
trace which vCPUs we consider.
A bit verbose, but quite useful, considering that
we may end up looking at, but then discarding, one
of more vCPU. This will help understand which ones
are skipped and wh
A credit reset basically means going through all the
vCPUs of a runqueue and altering their credits, as a
consequence of a 'scheduling epoch' having come to an
end.
Blocked or runnable vCPUs are fine, all the credits
they've spent running so far have been accounted to
them when they were scheduled
So that they're all close among each other, and
also near to the comment describind the runqueue
organization (which is also moved).
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 572 +
For Credit2, in both the trace records, inside Xen,
and in their parsing, in xenalyze.
In fact, it is a lot easier to figure out how much
negative credits have gone for a certain vCPU by
looking at a negative integer, rather than to an
overflowed unsigned.
Signed-off-by: Dario Faggioli
---
Cc: G
In fact, whether or not a pCPU has been tickled, and is
therefore about to re-schedule, is something we look at
and base decisions on in various places.
So, let's make sure that we do that basing on accurate
information.
While there, also tweak a little bit smt_idle_mask_clear()
(used for impleme
Hello,
This series contains mostly style or cosmetic fixes for Credit2, with the
following two exceptions:
- 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6);
- some tracing improvements (last 3 patches).
More info on the specific changelogs.
The series is also available as
There isn't any particular reason for the accessor helpers
to be macro, so turn them into 'static inline'-s, which are
better.
Note that it is necessary to move the function definitions
below the structure declarations.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George
There is no reason for having pretty much all of the
functions whose names begin with double underscores
('__') to actually look like that.
In fact, that is misleading and makes the code hard
to read and understand. So, remove the '__'-s.
The only two that we keep are __runq_insert() and
__runq_a
Most of the comments describing the meaning of the
vCPU flags used by the scheduler miss the 'wings' (or
have other minor style issues).
Also, use 1U (instead of 1) as the base of shiftings.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
-
flight 104668 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104668/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8b17ad862c235b3226c3d118e5b2f929860ef7ec
baseline version:
ovmf 2bdfb11df9ca0ea0a136e
flight 104671 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104671/
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
flight 104669 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104669/
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
This run is configured for baseline tests only.
flight 68459 qemu-upstream-4.2-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68459/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd6
On Wed, Jan 25, 2017 at 09:31:15AM -0600, Eric DeVolder wrote:
[...]
> diff --git a/kexec/kexec.c b/kexec/kexec.c
> index 500e5a9..ec16247 100644
> --- a/kexec/kexec.c
> +++ b/kexec/kexec.c
> @@ -51,6 +51,9 @@
> #include "kexec-lzma.h"
> #include
>
> +#define KEXEC_LOADED_PATH "/sys/kernel/kex
On Wed, Jan 25, 2017 at 04:20:30PM -0600, Doug Goldstein wrote:
> On 1/25/17 4:11 PM, Daniel Kiper wrote:
> > This way Xen can be loaded on EFI platforms using GRUB2 and
> > other boot loaders which support multiboot2 protocol.
> >
> > Signed-off-by: Daniel Kiper
> > ---
> > v13 - suggestions/fix
Hi Tamas,
On 25/01/2017 20:02, Tamas K Lengyel wrote:
During an SMC trap it is possible that the user may change the memory
By user, do you mean the monitor application?
from where the SMC was fetched. However, without flushing the icache
the SMC may still trigger if the pCPU was idle during
Hi Tamas,
On 25/01/2017 16:12, 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_acce
flight 104666 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104666/
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 1/25/17 4:11 PM, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper
> ---
> v13 - suggestions/fixes:
> - move vga_text_buffer and efi_platform to .init.data section
>
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory fro
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-b
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e6f6ef1..24b4b23 100644
---
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file con
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
Reviewe
Hi,
I am sending thirteenth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known/confirmed issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS pl
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
---
v13 - suggestions/fixes:
- move vga_text_buffer and efi_platform to .init.data section
(suggested by Jan Beulich),
- reduce number of err
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
This run is configured for baseline tests only.
flight 68458 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68458/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
flight 104664 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104664/
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
This run is configured for baseline tests only.
flight 68457 linux-3.16 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68457/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 1 build-check(1)
flight 104661 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104661/
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 01/25/2017 10:02 PM, Tamas K Lengyel wrote:
> During an SMC trap it is possible that the user may change the memory
> from where the SMC was fetched. However, without flushing the icache
> the SMC may still trigger if the pCPU was idle during the trap. Flush
> the icache to ensure consistency.
>
During an SMC trap it is possible that the user may change the memory
from where the SMC was fetched. However, without flushing the icache
the SMC may still trigger if the pCPU was idle during the trap. Flush
the icache to ensure consistency.
Signed-off-by: Tamas K Lengyel
---
Cc: Razvan Cojocaru
flight 104643 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104643/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104633
test-amd64-amd64-xl-qemuu-
flight 104658 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104658/
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 01/25/2017 12:33 PM, Joao Martins wrote:
> 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 som
flight 104640 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104640/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl
Hi Stefano,
On 24/01/17 20:07, 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 of ACPI, some data may come
from ASL,
T
On Wed, 25 Jan 2017, Paul Durrant wrote:
> On 25 January 2017, at 17:54, Stefano Stabellini
> wrote:
>
> >
> >
> >On Wed, 25 Jan 2017, Paul Durrant wrote:
> >> > -Original Message-
> >> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> >> > Sent: 24 January 2017 23:49
> >> > T
On 25 January 2017, at 17:54, Stefano Stabellini wrote:
>
>
>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...@lis
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
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
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:
> 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:
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
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
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
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
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
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
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
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
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
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
> -
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 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 --
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
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
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
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 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,
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
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
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
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, 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 (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
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
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/
... 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/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
1 - 100 of 164 matches
Mail list logo
