flight 129573 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129573/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
This run is configured for baseline tests only.
flight 75580 xen-4.11-testing real [real]
http://osstest.xensource.com/osstest/logs/75580/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail baseline
flight 129492 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129492/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail in 129438 pass in 129492
On 07/11/2018 10:30, Sander Eikelenboom wrote:
> Hi Juergen / Boris,
>
> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
> branch pulled on top.
> Unfortunately i was seeing guests lockup after some time, see below for the
> logging from one of the guest
> which i
Hi all,
I'm trying to build and run Linux (Debian) on top of Xen on a Hikey960
ARM board but am having trouble.
I've been following Konrad's guide on the Wiki (at
https://wiki.xenproject.org/wiki/HiKey960), namely:
* I have upgraded the board's base firmware to support UEFI
* I am building the
Hi Ian,
I just tested a manual install of a Win10-1703-x86 iso, with about as much the
same
xen config as the OSStest has.
The install succeeds in about an hour on my machine, with networking (DHCP) up
and running,
without the need for any extra drivers.
So i haven't ran into the issue
flight 129491 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 129353
Tests which did not
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
Introduce new boot parameter xsm to choose which xsm module is enabled,
and set default to dummy. And add new option in Kconfig to choose the
default XSM implementation.
Signed-off-by: Xin Li
Acked-by: Daniel De Graaf
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad
When SILO is enabled, there would be no page-sharing or event notifications
between unprivileged VMs (no grant tables or event channels).
Signed-off-by: Xin Li
Acked-by: Daniel De Graaf
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano
Filling dummy module's hook to null value of xsm_operations structure
will generate debug message. This becomes boot time spew for module
like silo, which only sets a few hooks of itself. So remove the printing
to avoid boot time spew.
Signed-off-by: Xin Li
---
CC: Daniel De Graaf
CC: George
this #define is unnecessary since XSM_INLINE is redefined in
xsm/dummy.h, it's a risk of build breakage, so remove it.
Signed-off-by: Xin Li
Reviewed-by: Jan Beulich
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
> -Original Message-
> From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov]
> Sent: Thursday, November 8, 2018 1:53 AM
> To: Xin Li (Talons) ; Andrew Cooper
>
> Cc: Xen-devel List
> Subject: Re: XSM SILO boot time spew
> If SILO is a good example of what a potential third XSM module
flight 129479 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129479/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR.
vs. 129313
flight 75579 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75579/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like
75551
This run is configured for baseline tests only.
flight 75578 xen-4.9-testing real [real]
http://osstest.xensource.com/osstest/logs/75578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 11 guest-start
On 11/7/18 5:45 PM, Sander Eikelenboom wrote:
> On 07/11/18 23:34, Boris Ostrovsky wrote:
>> On 11/7/18 4:30 AM, Sander Eikelenboom wrote:
>>> Hi Juergen / Boris,
>>>
>>> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
>>> branch pulled on top.
>>> Unfortunately i was
On 07/11/18 23:34, Boris Ostrovsky wrote:
> On 11/7/18 4:30 AM, Sander Eikelenboom wrote:
>> Hi Juergen / Boris,
>>
>> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
>> branch pulled on top.
>> Unfortunately i was seeing guests lockup after some time, see below for
On 11/7/18 4:30 AM, Sander Eikelenboom wrote:
> Hi Juergen / Boris,
>
> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
> branch pulled on top.
> Unfortunately i was seeing guests lockup after some time, see below for the
> logging from one of the guest
> which i was
flight 129544 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129544/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 18dc8b4048399adec12778ca71088f1308da838f
baseline version:
freebsd
flight 129468 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
129426
On Wed, 7 Nov 2018, Julien Grall wrote:
> On 07/11/2018 12:18, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 07/11/2018 00:32, Stefano Stabellini wrote:
> > > On Mon, 22 Oct 2018, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 09/10/2018 00:37, Stefano Stabellini wrote:
> > > > >
On Wed, Nov 07, 2018 at 07:49:54PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Wed, Nov 7, 2018 at 4:49 PM Marc-André Lureau
> wrote:
> >
> > The following patch is going to add compatiblity parameters for
> > qemu <= 3.1.
> >
>
> I realize this may be good enough for x86 i440/q35 machines, but
flight 129564 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129564/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 09/10/18 16:21, Sergey Dyasli wrote:
> Scrubbing RAM during boot may take a long time on machines with lots
> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
> initially so they will eventually be scrubbed in idle-loop on every
> online CPU.
>
> It's guaranteed that the
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree:
Hi Jan,
On 06/11/2018 15:48, Jan Beulich wrote:
On 02.10.18 at 12:38, wrote:
On 02/10/2018 11:18, Jan Beulich wrote:
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is
On Thu, 2018-10-11 at 15:47 +0200, Dario Faggioli wrote:
> For doing load balancing between runqueues, we check the load of each
> runqueue, select the one more "distant" than our own load, and then
> take
> the proper runq lock and attempt vcpu migrations.
>
> If we fail to take such lock, we
On Fri, 2018-10-12 at 19:43 +0200, Dario Faggioli wrote:
> Hello,
>
> Here it comes, core-scheduling for Credit2 as well. Well, this time,
> it's actually group-scheduling (see below).
>
> git://xenbits.xen.org/people/dariof/xen.git rel/sched/credit2/group-
> scheduling-RFCv1
>
>
On Thu, 2018-10-11 at 15:44 +0200, Dario Faggioli wrote:
> Load balancing, when happening, at the end of a "scheduler epoch",
> can
> trigger vcpu migration, which in its turn may call runq_tickle(). If
> the
> cpu where this happens was idle, but we're now going to schedule a
> vcpu
> on it,
On 10/31/2018 11:19 PM, Xin Li (Talons) wrote:
In patchset v4, we call register_xsm() to setup silo module.
This debug log is to check if some ops not overrided by the module.
I thought this is OK, since the log level is debug.
I think calling register_xsm() is good,
if we do want to suppress
On 07/11/18 17:01, Juergen Gross wrote:
> Commit 9da3f2b7405440 ("x86/fault: BUG() when uaccess helpers fault on
> kernel addresses") introduced a regression for booting Xen PV guests.
>
> Xen PV guests are using __put_user() and __get_user() for accessing the
> p2m map (physical to machine frame
On Wed, Nov 07, 2018 at 08:06:00AM -0700, Jan Beulich wrote:
> >>> On 07.11.18 at 12:11, wrote:
> > On Mon, Nov 05, 2018 at 09:56:13AM -0700, Jan Beulich wrote:
> >> >>> On 30.10.18 at 16:41, wrote:
> >> > BAR map/unmap is a long running operation that needs to be preempted
> >> > in order to
Commit 9da3f2b7405440 ("x86/fault: BUG() when uaccess helpers fault on
kernel addresses") introduced a regression for booting Xen PV guests.
Xen PV guests are using __put_user() and __get_user() for accessing the
p2m map (physical to machine frame number map) as accesses might fail
in case of not
flight 129535 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 129466 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129466/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 128792
On Wed, Nov 07, 2018 at 04:36:08PM +, Sergey Dyasli wrote:
> On 07/11/2018 12:17, Wei Liu wrote:
> > On Wed, Nov 07, 2018 at 11:11:49AM +, Sergey Dyasli wrote:
> >> Scrubbing RAM during boot may take a long time on machines with lots
> >> of RAM. Add 'idle' option to bootscrub which marks
On 07/11/2018 12:17, Wei Liu wrote:
> On Wed, Nov 07, 2018 at 11:11:49AM +, Sergey Dyasli wrote:
>> Scrubbing RAM during boot may take a long time on machines with lots
>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>> initially so they will eventually be scrubbed in
On Wednesday, November 7, 2018 10:42 AM, Ian Jackson wrote:
> Are these commitids from xen.git#master and the corresponding
> qemu-xen.git branch ?
Sorry, no, a few of those were from xen.git#staging-4.9 and
qemu-xen.git#staging-4.9.
Here's the same list, but with commit ids for the same
Hi
On Wed, Nov 7, 2018 at 4:49 PM Marc-André Lureau
wrote:
>
> The following patch is going to add compatiblity parameters for
> qemu <= 3.1.
>
I realize this may be good enough for x86 i440/q35 machines, but what
about other machines & architectures?
What do we officially support, for
Stewart Hildebrand writes ("RE: [Xen-devel] preparations for 4.11.1 and 4.8.5"):
> Are you still entertaining backports for 4.8.x?
> Also, are we interested in being able to build 4.8.x with newer gcc?
Many of these are tools things which fall in my bailiwick.
> If so, the following for xen
flight 129555 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129555/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 07/11/2018 16:06, Daniel Kiper wrote:
> On Wed, Nov 07, 2018 at 11:49:38AM +0100, Daniel Kiper wrote:
>> On Tue, Nov 06, 2018 at 09:54:54AM -0700, Jan Beulich wrote:
>> On 02.11.18 at 18:59, wrote:
It’s time again for the x86 community call: for the agenda see
>>> On 07.11.18 at 16:03, wrote:
> On Monday, October 8, 2018 9:06 AM, Jan Beulich wrote:
>> both releases are due in about a month's time. Please point out
>> backports you find missing from their respective staging branches,
>> but which you consider relevant. On top of what I've just pushed
>>
On 11/7/18 5:49 AM, Daniel Kiper wrote:
> On Tue, Nov 06, 2018 at 09:54:54AM -0700, Jan Beulich wrote:
> On 02.11.18 at 18:59, wrote:
>>> It’s time again for the x86 community call: for the agenda see
>>> https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1
>>>
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
On Wed, Nov 07, 2018 at 11:49:38AM +0100, Daniel Kiper wrote:
> On Tue, Nov 06, 2018 at 09:54:54AM -0700, Jan Beulich wrote:
> > >>> On 02.11.18 at 18:59, wrote:
> > > It’s time again for the x86 community call: for the agenda see
> > >
>>> On 07.11.18 at 12:11, wrote:
> On Mon, Nov 05, 2018 at 09:56:13AM -0700, Jan Beulich wrote:
>> >>> On 30.10.18 at 16:41, wrote:
>> > BAR map/unmap is a long running operation that needs to be preempted
>> > in order to avoid overrunning the assigned vCPU time (or even
>> > triggering the
On Monday, October 8, 2018 9:06 AM, Jan Beulich wrote:
> All,
>
> both releases are due in about a month's time. Please point out
> backports you find missing from their respective staging branches,
> but which you consider relevant. On top of what I've just pushed
> there I have
>
> 2fb57e4bee
>>> On 07.11.18 at 11:47, wrote:
> On Mon, Nov 05, 2018 at 09:46:22AM -0700, Jan Beulich wrote:
>> >>> On 30.10.18 at 16:41, wrote:
>> > When switching the memory decoding bit in the command register the
>> > rest of the changes where dropped, leading to only the memory decoding
>> > bit being
On 07/11/2018 13:21, Daniel Kiper wrote:
> On Fri, Nov 02, 2018 at 01:37:24PM +0100, Juergen Gross wrote:
>> With Xen PVH mode adding a new machine type the machine related headers
>> need to be present for the build to succeed. Most of the headers just
>> need to include the related common i386
This run is configured for baseline tests only.
flight 75577 xen-4.10-testing real [real]
http://osstest.xensource.com/osstest/logs/75577/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-rumprun-i386 17
On 06/11/18 12:07, Sergey Dyasli wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index dfd08e2d0a..c8bc8e6d11 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -57,6 +57,16 @@ void nvmx_cpu_dead(unsigned int cpu)
>
On Tue, Nov 06, 2018 at 12:07:58PM +, Sergey Dyasli wrote:
> The size of Xen's virtual vmcs region is 4096 bytes (see comment about
> Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
> it to the guest in case when VMCS shadowing is not available instead of
> providing
On Tue, Nov 06, 2018 at 12:07:53PM +, Sergey Dyasli wrote:
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Hi Dario,
On 09/10/2018 17:46, Dario Faggioli wrote:
On Tue, 2018-10-09 at 12:59 +0200, Milan Boberic wrote:
Hi,
Hi Milan,
I'm testing Xen Hypervisor 4.10 performance on UltraZed-EG board with
carrier card.
I created bare-metal application in Xilinx SDK.
In bm application I:
-
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 November 2018 13:09
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Ian Jackson ;
> Wei Liu
> Subject: Re: [Xen-devel] [PATCH v3 4/5] tools/misc: fix hard tabs in xen-
> hvmctx.c
>
> On Wed, Nov 07,
On 07/11/18 08:57, Paul Durrant wrote:
>>
>>> static inline struct page_info *get_page_from_gfn(
>>> -struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
>>> +struct domain *d, gfn_t gfn, p2m_type_t *t, p2m_query_t q)
>>> {
>>> struct page_info *page;
>>> +mfn_t
Hi Andrew,
On 06/11/2018 20:11, Andrew Cooper wrote:
This looks like it would be cleaner by not splitting mfn out into a
separate variable.
page = mfn_to_page(_mfn(gfn_x(gfn)));
return mfn_valid(mfn) && get_page(page, d) ? page : NULL;
The only reason this looks odd is because of the mfn =>
On Wed, Nov 07, 2018 at 10:52:22AM +, Paul Durrant wrote:
> Also add emacs boilerplate to avoid future problems.
>
> Purely cosmetic. No functional change.
>
> Signed-off-by: Paul Durrant
> Acked-by: Wei Liu
I have pushed this patch to staging.
Hi Paul,
On 07/11/2018 09:24, Paul Durrant wrote:
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 06 November 2018 19:15
To: sstabell...@kernel.org; xen-devel@lists.xenproject.org
Cc: Julien Grall ; Andrew Cooper
; George Dunlap ; Ian
Jackson ; Jan Beulich ;
On Tue, Nov 06, 2018 at 07:14:53PM +, Julien Grall wrote:
> From: Benjamin Sanda
>
> Modified to provide building of the xenalyze binary for both ARM and
> x86 platforms. The xenalyze binary is now built as part of the BIN
> list for both platforms.
>
> Signed-off-by: Benjamin Sanda
>
On Wed, Nov 07, 2018 at 12:53:24PM +, Andrew Cooper wrote:
> Clang reports:
>
> xen-cpuid.c:307:29: error: format specifies type 'unsigned long' but the
> argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
>
> msrs[l].idx, msrs[l].val);
>
Clang reports:
xen-cpuid.c:307:29: error: format specifies type 'unsigned long' but the
argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
msrs[l].idx, msrs[l].val);
^~~
Use PRIx64 instead.
Signed-off-by: Andrew
On Wed, Nov 07, 2018 at 12:42:54PM +, Andrew Cooper wrote:
> On 07/11/18 12:31, Wei Liu wrote:
> > Add two gcc builds. Clang builds are known to be broken at the moment.
> >
> > Signed-off-by: Wei Liu
>
> Would it be wise to have a RANDCONFIG build as well?
Sure. It appears that we forgot
On 07/11/18 12:31, Wei Liu wrote:
> Add two gcc builds. Clang builds are known to be broken at the moment.
>
> Signed-off-by: Wei Liu
Would it be wise to have a RANDCONFIG build as well?
~Andrew
___
Xen-devel mailing list
hostmem-file and hostmem-memfd use the whole object path for the
memory region name, and hostname-ram uses only the path component (the
object id, or canonical path basename):
qemu -m 1024 -object memory-backend-file,id=mem,size=1G,mem-path=/tmp/foo -numa
node,memdev=mem -monitor stdio
(qemu)
All qdev_prop_register_global() set _fatal for errp, except
'-rtc driftfix=slew', which arguably should also use _fatal, as
otherwise failing to apply the property would only report a warning.
Signed-off-by: Marc-André Lureau
---
include/hw/qdev-core.h| 6 --
hw/core/qdev-properties.c |
The following patches are going to implement post_init callbacks for
settings properties. The interface post_init are called before the
instance post_init, so the default interface behaviour can be
overriden if necessary.
Signed-off-by: Marc-André Lureau
---
qom/object.c| 8
It's now possible to use the common function.
Teach object_apply_global_props() to warn if Error argument is NULL.
Signed-off-by: Marc-André Lureau
---
hw/core/qdev-properties.c | 24 ++--
qom/object.c | 6 +-
2 files changed, 7 insertions(+), 23
The following patch is going to add compatiblity parameters for
qemu <= 3.1.
Signed-off-by: Marc-André Lureau
---
include/hw/compat.h | 3 +++
include/hw/i386/pc.h | 3 +++
hw/i386/pc_piix.c| 21 ++---
hw/i386/pc_q35.c | 19 +--
4 files changed, 41
Let's make compatiblity properties an interface, so that objects other
than QDev can benefit from having machine compatiblity properties.
Signed-off-by: Marc-André Lureau
---
include/hw/boards.h| 2 ++
hw/core/compat-props.c | 43 ++
hw/core/qdev.c
Considering that CPU features are provided via command line, the
global_props are now all user-provided globals. No need to track this
anymore for qdev_prop_check_globals().
Signed-off-by: Marc-André Lureau
---
include/hw/qdev-core.h | 3 --
hw/core/qdev-properties.c | 4 ---
A step towards being able to call object_apply_global_props().
Signed-off-by: Marc-André Lureau
---
hw/core/qdev-properties.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index
Interfaces don't have instance, let's make the interface type really
abstract to avoid confusion.
Signed-off-by: Marc-André Lureau
---
include/hw/acpi/acpi_dev_interface.h | 6 +-
include/hw/arm/linux-boot-if.h | 5 +
include/hw/fw-path-provider.h| 4 +---
The function is only used by a test, move it there.
Signed-off-by: Marc-André Lureau
Reviewed-by: Eduardo Habkost
---
include/hw/qdev-properties.h | 1 -
hw/core/qdev-properties.c | 9 -
tests/test-qdev-global-props.c | 18 ++
3 files changed, 14 insertions(+),
Machine & Accel props are not provided by user. Let's not mix them
with the global properties.
Call a new helper function object_apply_global_props() during
device_post_init().
Add a stub for current_machine, so qemu-user and tests can find a
fallback symbol when linking with QDev.
The
Hi,
During "[PATCH v2 05/10] qom/globals: generalize
object_property_set_globals()" review, Eduardo suggested to rework the
GlobalProperty handling, so that -global is limited to QDev only and
we avoid mixing the machine compats and the user-provided -global
properties (instead of generalizing
Instead of accepting any Object*, change user_creatable_complete() to
require a UserCreatable*. Modify the callers to pass the appropriate
argument, removing redundant dynamic cast checks in object creation.
Signed-off-by: Marc-André Lureau
Reviewed-by: Igor Mammedov
---
global_props is only used for Xen xen_compat_props. It's a static
array of GlobalProperty, like machine globals in SET_MACHINE_COMPAT().
Let's register the globals the same way, without extra copy allocation.
Signed-off-by: Marc-André Lureau
Reviewed-by: Igor Mammedov
---
Instead, it returns 1 if an error was detected, which is the case for:
/qdev/properties/dynamic/global/subprocess:
warning: global dynamic-prop-type-bad.prop3 has invalid class name
warning: global nohotplug-type.prop5=105 not used
warning: global nondevice-type.prop6 has invalid class name
Unfortunately sharing dockerfile has proven impossible: 1) the base
image is different; 2) Arm doesn't need libc-dev-i386; 3) Arm needs
libfdt-dev.
Signed-off-by: Wei Liu
---
.../build/debian/unstable-arm64v8.dockerfile | 48 ++
1 file changed, 48 insertions(+)
create
Hi all
This is my first attempt to quickly get something useful for Arm in Gitlab CI
with a machine borrowed from Packet.net.
The runner is configured manually at the moment (see below). It is tagged with
arm,arm64,docker so it will only run Arm64 jobs. Idealy we should build it with
Terraform
The restrictions are mostly from Travis CI days when cross-compilation
was not feasible. Now we will be building natively on Arm, remove
those lines.
Signed-off-by: Wei Liu
---
automation/scripts/build | 6 --
1 file changed, 6 deletions(-)
diff --git a/automation/scripts/build
Add two gcc builds. Clang builds are known to be broken at the moment.
Signed-off-by: Wei Liu
---
.gitlab-ci.yml | 22 ++
1 file changed, 22 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index bf6bf7d895..f2db6dfa53 100644
--- a/.gitlab-ci.yml
+++
On 07/11/2018 12:18, Julien Grall wrote:
Hi Stefano,
On 07/11/2018 00:32, Stefano Stabellini wrote:
On Mon, 22 Oct 2018, Julien Grall wrote:
Hi,
On 09/10/2018 00:37, Stefano Stabellini wrote:
reserved-memory regions should be mapped as normal memory.
This is already the case with
On Fri, Nov 02, 2018 at 01:37:26PM +0100, Juergen Gross wrote:
> include/grub/offsets.h needs some defines for Xen PVH mode.
>
> Add them. While at it line up the values in the surrounding lines to
> start at the same column.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
Daniel
On Fri, Nov 02, 2018 at 01:37:24PM +0100, Juergen Gross wrote:
> With Xen PVH mode adding a new machine type the machine related headers
> need to be present for the build to succeed. Most of the headers just
> need to include the related common i386 headers. Add those to the tree.
>
>
Hi Stefano,
On 07/11/2018 00:32, Stefano Stabellini wrote:
On Mon, 22 Oct 2018, Julien Grall wrote:
Hi,
On 09/10/2018 00:37, Stefano Stabellini wrote:
reserved-memory regions should be mapped as normal memory.
This is already the case with p2m_mmio_direct_c. The hardware domain should
have
On 07/11/2018 13:02, Andrew Cooper wrote:
> On 07/11/18 11:55, Andrew Cooper wrote:
>> On 07/11/18 11:30, Juergen Gross wrote:
>>> + return ret;
>>> }
>>>
>>> static inline int xen_safe_read_ulong(unsigned long *addr, unsigned long
>>> *val)
>>> {
>>> - return __get_user(*val, (unsigned
On Fri, Nov 02, 2018 at 01:37:23PM +0100, Juergen Gross wrote:
> Some common code needs to be special cased for Xen PVH mode. This hits
> mostly Xen PV mode specific areas.
>
> Split include/grub/i386/pc/int_types.h off from
> include/grub/i386/pc/int.h to support including this file later from
>
On 07/11/18 11:55, Andrew Cooper wrote:
> On 07/11/18 11:30, Juergen Gross wrote:
>> +return ret;
>> }
>>
>> static inline int xen_safe_read_ulong(unsigned long *addr, unsigned long
>> *val)
>> {
>> -return __get_user(*val, (unsigned long __user *)addr);
>> +int ret = 0;
>> +
flight 129463 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129463/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
On 07/11/18 11:30, Juergen Gross wrote:
> Commit 9da3f2b7405440 ("x86/fault: BUG() when uaccess helpers fault on
> kernel addresses") introduced a regression for booting Xen PV guests.
>
> Xen PV guests are using __put_user() and __get_user() for accessing the
> p2m map (physical to machine frame
> -Original Message-
> From: Roger Pau Monne
> Sent: 07 November 2018 11:49
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v3 3/5] viridian: define type for the
> 'virtual VP assist page'
>
> On Wed, Nov 07, 2018
On Wed, Nov 07, 2018 at 10:52:21AM +, Paul Durrant wrote:
> The specification [1] defines a type so we should use it, rather than just
> OR-ing and AND-ing magic bits.
>
> No functional change.
>
> NOTE: The type defined in the specification does include an anonymous
> sub-struct in
On Wed, Nov 07, 2018 at 10:52:20AM +, Paul Durrant wrote:
> ...into new 'time' module.
>
> This patch reduces the size of the main viridian source module by
> moving time related enlightenments into their own source module. This is
> done in anticipation of implementation of more such
On Wed, Nov 07, 2018 at 10:52:19AM +, Paul Durrant wrote:
> ...into new 'synic' module.
>
> The SynIC (synthetic interrupt controller) is specified [1] to be a super-
> set of a virtualized LAPIC, and its definition encompasses all
> enlightenments related to virtual interrupt control.
>
>
On Fri, Nov 02, 2018 at 01:37:21PM +0100, Juergen Gross wrote:
> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> by passing the RSDP address via the boot parameters to Linux.
>
> The new protocol version 2.14 requires to set version to 0x8000 ored
> with the actually use
On Mon, Nov 05, 2018 at 10:07:24AM -0700, Jan Beulich wrote:
> >>> On 30.10.18 at 16:41, wrote:
> > Make sure the MSIX MMIO regions don't have p2m entries setup, so that
> > accesses to them trap into the hypervisor and can be handled by vpci.
> >
> > This is a side-effect of commit 042678762
1 - 100 of 117 matches
Mail list logo
