On 25/09/17 10:01, Jan Beulich wrote:
> Just like done in d2bd05d88d ("xen-pciback: return proper values during
> BAR sizing") for the ROM BAR, ordinary ones also shouldn't compare the
> written value directly against ~0, but consider the r/o bits at the
> bottom (if any).
>
> Signed-off-by: Jan B
On 17-09-25 17:15:21, Roger Pau Monn� wrote:
> On Sat, Sep 23, 2017 at 09:48:11AM +, Yi Sun wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
[...]
> > -case XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA:
> > -ret = psr_get_val(d, domctl->u.psr_cat_op.target,
> > +
On 26.09.2017 02:08, Alistair Francis wrote:
> Replace a large number of the fprintf(stderr, "*\n" calls with
> error_report(). The functions were renamed with these commands and then
> compiler issues where manually fixed.
>
> find ./* -type f -exec sed -i \
> 'N;N;N;N;N;N;N;N;N;N;N;N; {s|fpr
flight 113817 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113817/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113784
test-armhf-armhf-libvirt-xsm 14 sav
Thanks for the explanation!
It looks like the code that caused the issue would be removed with this
patch?
staging: atomisp: use clock framework for camera clocks
https://lkml.org/lkml/2017/9/20/712
--
John Thomson
___
Xen-devel mailing list
Xen-deve
flight 113816 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113816/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 broken
test-xtf-amd64-amd64-5
On 9/20/2017 6:37 PM, Sameer Goel wrote:
> This driver follows an approach similar to smmu driver. The intent here
> is to reuse as much Linux code as possible.
> - Glue code has been introduced to bridge the API calls.
> - Called Linux functions from the Xen IOMMU function calls.
> - Xen modific
On Mon, 11 Sep 2017, George Dunlap wrote:
> +### RTDS based Scheduler
> +
> +Status: Experimental
> +
> +A soft real-time CPU scheduler built to provide guaranteed CPU capacity to
> guest VMs on SMP hosts
> +
> +### ARINC653 Scheduler
> +
> +Status: Supported, Not security supported
> +
>
Hi Jan,
Yes, after including the __STRICT_ANSI__ check the headers.chk check
passes. But I had to include string header file (after suggestion from Stefano)
for fixing the headers++.chk.
I have pasted the changes below:
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 1299b19..c90f
On Sun, 24 Sep 2017, Michael Tokarev wrote:
> 23.09.2017 19:05, Michael Tokarev wrote:
> > 28.06.2017 01:04, Stefano Stabellini wrote:
> >> Rather than constructing a local structure instance on the stack, fill
> >> the fields directly on the shared ring, just like other (Linux)
> >> backends do. B
Hi Paul,
On 09/14/2017 03:33 PM, Paul Durrant wrote:
Julien,
That should not be too hard. We have a driver install agent for XenServer that
will manage all the necessary driver staging and required reboots. Hopefully it
should mainly be a question of building that installer to pick up driv
Hi,
I have a problem with Xen 4.8.2 (or Linux 4.9.51 as dom0 kernel) :
calls to DISCARD command from the DomU frequently hang.
I also have the problem with Xen 4.8.1 and Linux 4.9 from Debian 9
(stretch) repositories.
Here logs from dom0 :
Sep 25 22:32:44 hyp04-sbg kernel: [ 7468.540610] INFO: t
This Patch allows a migration precopy policy to be specified.
The precopy phase of the xc_domain_save() live migration algorithm has
historically been implemented to run until either a) (almost) no pages
are dirty or b) some fixed, hard-coded maximum number of precopy
iterations has been exceeded.
Provide an implementation of the old policy as a callback in
libxl and plumb it through the IPC machinery to libxc.
This serves as an example for defining a libxl policy,
and provides no advantage over the default policy in libxc.
Signed-off-by: Joshua Otto
Reviewed-by: Roger Pau Monné
---
too
Hi all,
v3:
In patch 2/3, have changed/added comments, removed iteration parmeter from
update_progress_string and made a few formatting corrections.
v2:
Have tidied some formatting, s.o.b Joshua, and added a RFC patch
showing how to use this in libxl.
v1:
Here I present a updated/modified su
Tidy up libxc's xc_domain_save, removing unused paramaters
max_iters and max_factor, making matching changes to libxl.
Signed-off-by: Joshua Otto
Signed-off-by: Jennifer Herbert
Reviewed-by: Paul Durrant
Acked-by: Wei Liu
---
tools/libxc/include/xenguest.h | 4 ++--
tools/libxc/xc_nomigrate
Hi, Bharat
On Mon, Sep 25, 2017 at 8:40 PM, bharat gohil wrote:
>
>
> On 25-Sep-2017 6:59 PM, "Julien Grall" wrote:
>
> Hi,
>
> I am using same setup.
> It just my guess because no response to key ctrl+a input.
>
> SoC has 8250 compitible UART.I will print character in receive handler of
> UART
flight 113815 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113815/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 113813 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113813/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs.
113387
Tests which
On 25-Sep-2017 6:59 PM, "Julien Grall" wrote:
Hi,
I am using same setup.
It just my guess because no response to key ctrl+a input.
SoC has 8250 compitible UART.I will print character in receive handler of
UART in Xen. Do we have any other hook test this?
One more thing, is big-little supported
On Mon, 2017-09-25 at 17:23 +0100, Julien Grall wrote:
> On 09/25/2017 03:07 PM, Dario Faggioli wrote:
> > Hey,
>
> Hi Dario,
>
Hi!
> > I don't see much in the logs, TBH, but both `xl vcpu-list' and the
> > 'r'
> > debug key seem to suggest that vCPU 0 is running, while the other
> > vCPUs
> > h
The ABI of {read,write}_msr() are required them to use x86_emul_hw_exception()
if they raise an exception with the emulator core.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/pv/emul-priv-op.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arch/x86/pv/e
Coverity points out that next is indeed NULL at times. Only try to read the
.cpuid_faulting field when we sure that next isn't NULL.
Fixes e7a370733bd "x86: replace arch_vcpu::cpuid_faulting with msr_vcpu_policy"
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/intel.c |
On 09/25/2017 03:07 PM, Dario Faggioli wrote:
Hey,
Hi Dario,
On Mon, 2017-09-25 at 09:46 +, osstest service owner wrote:
flight 113807 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113807/
So, triggered by this:
Tests which are failing intermittently (not
On Sat, Sep 23, 2017 at 09:48:11AM +, Yi Sun wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1439,60 +1439,60 @@ long arch_do_domctl(
> }
> break;
>
> -case XEN_DOMCTL_psr_cat_op:
> -switch ( domctl->u.psr_cat_op.cmd )
> +case XEN_DOM
Hi Jan and al,
- On Sep 21, 2017, at 9:12 AM, Jan Beulich jbeul...@suse.com wrote:
> And did you verify that the OS actually makes an attempt to clear
> this mask-all flag? If such an attempt doesn't have the intended
> effect, finding the problem location in the code and sending a
> fix can'
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2017 17:00
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ;
> Stefano Stabellini ; xen-de...@lists.xenproject.org;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PAT
flight 113812 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs.
113666
test-amd64-i386-x
>>> On 18.09.17 at 17:31, wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -354,6 +354,9 @@ static void hvm_update_ioreq_evtchn(struct
> hvm_ioreq_server *s,
> }
> }
>
> +#define HANDLE_BUFIOREQ(s) \
> +(s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
flight 113814 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113814/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2017 16:31
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: RE: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV
> domain to map guest mfns
>
> >>> On 25
>>> On 25.09.17 at 16:56, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
>> Beulich
>> Sent: 25 September 2017 15:50
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-
>> de...@lists.xenproject.org
>> Subject: Re: [Xen-devel] [PATC
>>> On 18.09.17 at 17:31, wrote:
> This patch adjusts the ioreq server code to use type-safe gfn_t values
> where possible. No functional change.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Roger Pau Monné
> Reviewed-by: Wei Liu
Again in case it matters
Acked-by: Jan Beulich
___
>>> On 18.09.17 at 17:31, wrote:
> This patch re-works much of the ioreq server initialization and teardown
> code:
>
> - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
> to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
> separately by outer function
>>> On 18.09.17 at 17:31, wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -33,6 +33,32 @@
>
> #include
>
> +static void set_ioreq_server(struct domain *d, unsigned int id,
> + struct hvm_ioreq_server *s)
> +{
> +ASSERT(id < MAX_NR
On Sat, Sep 23, 2017 at 09:48:10AM +, Yi Sun wrote:
> This patch creates MBA feature document in doc/features/. It describes
> key points to implement MBA which is described in details in Intel SDM
^ detail
> "Introduction to Memory Bandwidth
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2017 15:23
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to
> acquire guest resources
>
> >>> On 18.09.17
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 25 September 2017 15:50
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV
>
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 25 September 2017 14:50
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add
> HYPERVISOR_memory_
>>> On 25.09.17 at 16:42, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 25 September 2017 14:03
>> >>> On 18.09.17 at 17:31, wrote:
>> The other aspect I don't understand is why this is needed for PV
>> Dom0, but not for PVH. The answer here can't be "because PVH
>> Dom0 isn't s
On 09/25/2017 09:59 AM, Juergen Gross wrote:
> Ping?
>
> On 06/09/17 19:36, Juergen Gross wrote:
>> With virt_spin_lock() being guarded by a static key the bare metal case
>> can be optimized by patching the call away completely. In case a kernel
>> running as a guest it can decide whether to use p
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2017 14:03
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map
> guest mfns
>
> >>> On 18.09.17 at 17
On Fri, Sep 22, 2017 at 02:07:25PM +0200, Juergen Gross wrote:
> Trying to call xengnttab_set_max_grants() with the same file handle
> might fail on some kernels, as this operation is allowed only once.
>
> This is a problem for the qdisk backend as blk_connect() can be
> called multiple times for
>
> [snip]
>
>
> > So i think David's NACK was mostly for the patchset having some hackish
> cosmetics.
>
> He didn't like 'do_flr' which made sense as the patchset did not do FLR.
> It made a bus-reset
> for more than one device (if those devices were assigned to pciback).
>
When I first wrote
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2017 15:29
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v7 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to
> .*gfn
>
> >>> On 18.09.17 at 17:31, w
>>> On 18.09.17 at 17:31, wrote:
> This patch changes use of bool_t to bool in the ioreq server code. It also
> fixes an incorrect indentation in a continuation line.
>
> This patch is purely cosmetic. No semantic or functional change.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Roger Pau Mo
>>> On 18.09.17 at 17:31, wrote:
> Since ioreq servers are only relevant to HVM guests and all the names in
> question unequivocally refer to guest frame numbers, name them all .*gfn
> to avoid any confusion.
>
> This patch is purely cosmetic. No semantic or functional change.
>
> Signed-off-by:
Current stability numbers are not 100%. In order to help track this
down, add a --rerun option which will run the same input twice,
resetting the state in between each run, and comparing the state
afterwards. If the state differs, call abort().
This allows AFL to help the process of tracking dow
x86_emulate() operates not only on state passed to it in
cpu_user_regs, but also on state currently found on the cpu: namely,
the FPU and XMM registers. At the moment, we re-zero (and/or
re-initialize) cpu_user_regs on every invocation, but leave the
cpu-stored state alone. In "persistent mode",
AFL considers a testcase to be a useful addition not only if there are
tuples exercised by that testcase which were not exercised otherwise,
but also if the *number* of times an individual tuple is exercised
changes significantly; in particular, if the number of the highes bit
changes (i.e., if it
From: Jan Beulich
fuzz_insn_fetch() is the only data access helper where it is possible
to see offsets larger than 4Gb in 16- or 32-bit modes, as we leave the
incoming rIP untouched in the emulator itself. The check is needed here
as otherwise, after successfully fetching insn bytes, we may end u
- Print the symbolic name rather than the number
- Explicitly state when data_read() fails due to EOI
Signed-off-by: George Dunlap
Reviewed-by: Wei Liu
---
Changes in v2:
- Add spaces around '='
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
---
tools/fuzz/x86_instruction_em
At the moment, AFL reckons that for any given input, 87% of it is
completely irrelevant: that is, it can change it as much as it wants
but have no impact on the result of the test; and yet it can't remove
it.
This is largely because we interpret the blob handed to us as a large
struct, including C
On Mon, Sep 25, 2017 at 08:25:43AM -0600, Jan Beulich wrote:
> >>> On 25.09.17 at 16:11, wrote:
> > On Mon, Sep 25, 2017 at 07:58:15AM -0600, Jan Beulich wrote:
> >> Wouldn't it be better then to pass both (as
> >> long as supported, if we really care about older compilers here)?
> >
> > I'm fine
...to generate a "normal" coverage-instrumented binary, suitable for
use with gcov or afl-cov.
This is slightly annoying because:
- Every object file needs to have been instrumented to work
effectively
- You generally want to have both an afl-instrumented binary and a
gcov-instrumented b
Rather than open-coding the "read" from the input file.
Signed-off-by: George Dunlap
---
v2:
- Use less dread-ful names
- Return bool rather than int
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
---
tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 31 ++
Once feof() returns true for a stream, it will continue to return true
for that stream until clearerr() is called (or the stream is closed
and re-opened).
In llvm-clang-fast-mode, the same file descriptor is used for each
iteration of the loop, meaning that the "Input too large" check was
broken -
Finding aggregate coverage for a set of test files means running each
afl-generated test case through the harness. At the moment, this is
done by re-executing afl-harness-cov with each input file. When a
large number of test cases have been generated, this can take a
significant amonut of time; a
Commit c07574b reorganized the way fuzzing was done, explicitly
creating a structure that the input data would be copied into.
Unfortunately, the cpu register state used by the emulator is on the
stack; it's cleared, but data is never copied into it.
If we're explicitly setting an entirely new cp
When generating coverage output, by default gcov generates output
filenames based only on the coverage file and the "leaf" source file,
not the full path. As a result, it uses the same name for
x86_emulate.c and x86_emulate/x86_emulate.c, generally overwriting the
second (which we actually are abo
This is in preparation for adding the option for a more "compact"
interpretation of the fuzzing data, in which we only change select
bits of the state.
Signed-off-by: George Dunlap
---
v2: Port over previous changes
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
---
tools/fuz
>>> On 25.09.17 at 16:11, wrote:
> On Mon, Sep 25, 2017 at 07:58:15AM -0600, Jan Beulich wrote:
>> Wouldn't it be better then to pass both (as
>> long as supported, if we really care about older compilers here)?
>
> I'm fine with that. -fno-PIE is supported a long time ago. I can fold in
> the fo
>>> On 18.09.17 at 17:31, wrote:
> Certain memory resources associated with a guest are not necessarily
> present in the guest P2M and so are not necessarily available to be
> foreign-mapped by a tools domain unless they are inserted, which risks
> shattering a super-page mapping.
Btw., I'm addit
On Mon, 2017-09-25 at 01:31 -0600, Jan Beulich wrote:
> > > > On 22.09.17 at 19:20, wrote:
> >
> > Signed-off-by: Anthony PERARD
>
> Would you mind clarifying in a brief description whether this is just
> routine catch up, or to bring in any specific changes we need?
>
What we have right now,
On Mon, Sep 25, 2017 at 07:58:15AM -0600, Jan Beulich wrote:
> >>> On 25.09.17 at 15:40, wrote:
> > --- a/tools/tests/x86_emulator/Makefile
> > +++ b/tools/tests/x86_emulator/Makefile
> > @@ -76,7 +76,7 @@ $(addsuffix .c,$(SIMD)) $(addsuffix -avx.c,$(filter
> > sse%,$(SIMD))):
> > ln -sf simd
Hey,
On Mon, 2017-09-25 at 09:46 +, osstest service owner wrote:
> flight 113807 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/113807/
>
So, triggered by this:
> Tests which are failing intermittently (not blocking):
> test-armhf-armhf-xl-credit2 16 guest-start
>>> On 25.09.17 at 15:29, wrote:
> On 25/09/17 14:02, Jan Beulich wrote:
> On 18.09.17 at 17:31, wrote:
>>> In the case where a PV domain is mapping guest resources then it needs make
>>> the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
>>> domid, so that the passed in g
Ping?
On 06/09/17 19:36, Juergen Gross wrote:
> With virt_spin_lock() being guarded by a static key the bare metal case
> can be optimized by patching the call away completely. In case a kernel
> running as a guest it can decide whether to use paravitualized
> spinlocks, the current fallback to th
>>> On 25.09.17 at 15:40, wrote:
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -76,7 +76,7 @@ $(addsuffix .c,$(SIMD)) $(addsuffix -avx.c,$(filter
> sse%,$(SIMD))):
> ln -sf simd.c $@
>
> $(TARGET): x86_emulate.o test_x86_emulator.o
> - $(HOS
>>> On 18.09.17 at 17:31, wrote:
> Certain memory resources associated with a guest are not necessarily
> present in the guest P2M and so are not necessarily available to be
> foreign-mapped by a tools domain unless they are inserted, which risks
> shattering a super-page mapping.
For grant table
PIE may (and commonly will) result in the binary being loaded above
the 4Gb boundary, which can't work with at least the VZEROUPPER compat
mode test.
Add -no-pie when appropriate so that linker won't generate a PIE
executable.
Reported-by: Wei Liu
Signed-off-by: Jan Beulich
Signed-off-by: Wei L
On 25/09/17 14:02, Jan Beulich wrote:
On 18.09.17 at 17:31, wrote:
>> In the case where a PV domain is mapping guest resources then it needs make
>> the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
>> domid, so that the passed in gmfn values are correctly treated as mfns
Hi,
On 09/25/2017 01:53 PM, bharat gohil wrote:
Hello Andrii,
I tried but no success.
It looks, Xen is not running.
I am a bit confused... on one of the previous e-mail you posted log from
Xen:
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed
Hello Bharat,
On 25.09.17 15:53, bharat gohil wrote:
Hello Andrii,
I tried but no success.
It looks, Xen is not running.
Or your dom0 kernel disabled serial port clock. Because from kernel
point of view it is left unused, like it happened to us with R-Car gen3
SoC. So we issued such a patch
On Mon, Sep 25, 2017 at 07:16:43AM -0600, Jan Beulich wrote:
> >
> > Actually I do have a wheezy chroot to verify that:
> >
> > (wheezy)wei@zion:/local/work$ gcc --version
> > gcc (Debian 4.6.3-14) 4.6.3
> >
> > (wheezy)wei@zion:/local/work$ gcc -no-pie
> > gcc: error: unrecognized option '-no-p
On Mon, Sep 25, 2017 at 07:09:51AM -0600, Jan Beulich wrote:
> > The build rune is in fact using HOSTCC to link the executable, hence we
> > need -fno-pie.
> >
This should be "we need -no-pie", sorry.
> > I'm not sure why omitting -fno-PIE is not a problem, but it works.
>
> All pretty confusin
This run is configured for baseline tests only.
flight 72155 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72155/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf baaa3cee1eafc044606ee9dc60ec091713f81b8b
baseline v
>>> On 25.09.17 at 15:01, wrote:
> On Mon, Sep 25, 2017 at 01:55:03PM +0100, Wei Liu wrote:
>> On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
>> > >>> On 25.09.17 at 13:43, wrote:
>> > > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
>> > >> >>> On 25.09.17 at 12:49,
On Mon, Sep 25, 2017 at 01:55:03PM +0100, Wei Liu wrote:
> On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
> > >>> On 25.09.17 at 13:43, wrote:
> > > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
> > >> >>> On 25.09.17 at 12:49, wrote:
> > >> > PIE may (and commonly wi
>>> On 25.09.17 at 14:55, wrote:
> On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
>> >>> On 25.09.17 at 13:43, wrote:
>> > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
>> >> >>> On 25.09.17 at 12:49, wrote:
>> >> > PIE may (and commonly will) result in the binary be
>>> On 18.09.17 at 17:31, wrote:
> In the case where a PV domain is mapping guest resources then it needs make
> the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
> domid, so that the passed in gmfn values are correctly treated as mfns
> rather than gfns present in the guest p
On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
> >>> On 25.09.17 at 13:43, wrote:
> > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
> >> >>> On 25.09.17 at 12:49, wrote:
> >> > PIE may (and commonly will) result in the binary being loaded above
> >> > the 4Gb boundary
Hello Andrii,
I tried but no success.
It looks, Xen is not running.
Thanks,
Bharat
On Mon, Sep 25, 2017 at 5:45 PM, Andrii Anisov
wrote:
> Hello Bharat,
>
>
> On 25.09.17 11:42, bharat gohil wrote:
>
>> Hello Wilk,
>>
>> I had try Ctrl+a three times and 'd' but no dump on the serial console.
>
flight 113809 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113809/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113765
test-amd64-i386-xl-qemut-win
Hello Bharat,
On 25.09.17 11:42, bharat gohil wrote:
Hello Wilk,
I had try Ctrl+a three times and 'd' but no dump on the serial console.
Its a way to switch to XEN debug console. In case you are using minicom,
you should press Ctrl+A six times, then you will see the line like
following:
> -Original Message-
> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com]
> Sent: 25 September 2017 13:03
> To: xen-devel@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; jbeul...@suse.com; konrad.w...@oracle.com;
> sstabell...@kernel.org; Tim (Xen.org)
> -Original Message-
> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com]
> Sent: 25 September 2017 13:03
> To: xen-devel@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; jbeul...@suse.com; konrad.w...@oracle.com;
> sstabell...@kernel.org; Tim (Xen.org)
> -Original Message-
> From: Petre Pircalabu [mailto:ppircal...@bitdefender.com]
> Sent: 25 September 2017 13:03
> To: xen-devel@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; jbeul...@suse.com; konrad.w...@oracle.com;
> sstabell...@kernel.org; Tim (Xen.org)
On Wed, Sep 20, Stefano Stabellini wrote:
> From: Olaf Hering
> g_malloc0_n is available since glib-2.24. To allow build with older glib
> versions use the generic g_new0, which is already used in many other
> places in the code.
> Fixes commit 3284fad728 ("xen-disk: add support for multi-page sh
>>> On 25.09.17 at 14:00, wrote:
> On 25/09/17 13:55, Andrew Cooper wrote:
>> On 25/09/17 11:00, Juergen Gross wrote:
>>> On very large hosts a pv-guest needs to know whether it will have to
>>> handle frame numbers larger than 32 bits in order to select the
>>> appropriate grant interface version
- print the return code of the last failed emulator operation
in hvm_dump_emulation_state.
- print the return code in sh_page_fault (SHADOW_PRINTK) to make the
distiction between X86EMUL_UNHANDLEABLE and X86EMUL_UNIMPLEMENTED.
Signed-off-by: Petre Pircalabu
Reviewed-by: Jan Beulich
---
Changed
If case of a vm_event with the emulate_flags set, if the instruction
is not implemented by the emulator, the monitor should be notified instead
of directly injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. a
Enforce the distinction between an instruction not implemented by the
emulator and the failure to emulate that instruction by defining a new
return code, X86EMUL_UNIMPLEMENTED.
This value should only be returned by the core emulator only if it fails to
properly decode the current instruction's opc
This patchset implements a mechanism which allows XEN to send first an event
if the emulator encountered an unsupported instruction.
The monitor application can choose to mitigate the error, for example to
singlestep
the instruction using the real processor and then resume execution of the normal
On 25/09/17 13:00, Juergen Gross wrote:
> On 25/09/17 13:55, Andrew Cooper wrote:
>> On 25/09/17 11:00, Juergen Gross wrote:
>>> On very large hosts a pv-guest needs to know whether it will have to
>>> handle frame numbers larger than 32 bits in order to select the
>>> appropriate grant interface v
>>> On 25.09.17 at 12:00, wrote:
> Leaf 4 of the Xen-specific CPUID leaves isn't mentioned at all in
> include/public/arch-x86/cpuid.h, the comments for leaf 5 don't tell
> anything about the sub-leaf semantics.
>
> Add comments to clarify the interface.
>
> Signed-off-by: Juergen Gross
Acked-
On 25/09/17 13:55, Andrew Cooper wrote:
> On 25/09/17 11:00, Juergen Gross wrote:
>> On very large hosts a pv-guest needs to know whether it will have to
>> handle frame numbers larger than 32 bits in order to select the
>> appropriate grant interface version.
>>
>> Add a new Xen specific CPUID nod
>>> On 25.09.17 at 12:00, wrote:
> On very large hosts a pv-guest needs to know whether it will have to
> handle frame numbers larger than 32 bits in order to select the
> appropriate grant interface version.
>
> Add a new Xen specific CPUID node to contain the maximum machine address
> width sim
On 25/09/17 11:00, Juergen Gross wrote:
> On very large hosts a pv-guest needs to know whether it will have to
> handle frame numbers larger than 32 bits in order to select the
> appropriate grant interface version.
>
> Add a new Xen specific CPUID node to contain the maximum machine address
> widt
>>> On 25.09.17 at 12:49, wrote:
> PIE may (and commonly will) result in the binary being loaded above
> the 4Gb boundary, which can't work with at least the VZEROUPPER compat
> mode test.
>
> Reported-by: Wei Liu
> Signed-off-by: Jan Beulich
> Signed-off-by: Wei Liu
> ---
> Cc: Jan Beulich
>
1 - 100 of 167 matches
Mail list logo
