Hi,
I am using chroot to cross compile xen. I am getting the error as per
the error log. I have installed libpixman. But still this is occuring.
what could be the possible reason?
Thanks and regards,
George
xen_chroot_log
Description: Binary data
___
Philippe Mathieu-Daudé writes:
> Patch created mechanically by rerunning:
>
> $ spatch --sp-file scripts/coccinelle/typecast.cocci \
> --macro-file scripts/cocci-macro-file.h \
> --dir . --in-place
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
>
On 05/07/18 05:51, Chenjia (C) wrote:
> Dear Juergen:
> Thank your for your help, Here are the message:
> - which kernel version?
> 1、The "xl info " information is:
>
> host : linux
> release: 4.4.103-92.56-default
> version: #1 SMP Wed Dec
From: Ihor Matushchak
Signed-off-by: Ihor Matushchak
---
docs/misc/arm/early-printk.txt | 1 +
xen/arch/arm/Rules.mk | 1 +
2 files changed, 2 insertions(+)
diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index f765f59..5574a91 100644
---
From: Ihor Matushchak
This patch enables earlyprintk for Rockchip rk3399 based SoC.
Ihor Matushchak (1):
xen:arm:earlyprintk configuration for rk3399 boards
docs/misc/arm/early-printk.txt | 1 +
xen/arch/arm/Rules.mk | 1 +
2 files changed, 2 insertions(+)
--
2.7.4
Hello,
I'm building dom0 kernel RPMs for the CentOS Xen project (
https://github.com/CentOS-virt7/xen-kernel) and it seems that the 4.9
branch isn't booting anymore as dom0. I recently built 4.9.110 and 4.9.111,
both give black screen and reboot while booting dom0. Our last successful
version is
flight 124986 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124986/
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
Dear Juergen:
Thank your for your help, Here are the message:
- which kernel version?
1、The "xl info " information is:
host : linux
release: 4.4.103-92.56-default
version: #1 SMP Wed Dec 27 16:24:31 UTC 2017 (2fd2155)
machine
flight 124939 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
> -Original Message-
> From: George Dunlap
> Sent: Thursday, July 5, 2018 12:55 AM
> To: Jan Beulich
> Cc: Xin Li ; Andrew Cooper
> ; Ming Lu ; Sergey Dyasli
> ; Wei Liu ; Xin Li (Talons)
> ; George Dunlap ; Stefano
> Stabellini ; xen-devel ;
> Konrad Rzeszutek Wilk ; Daniel de Graaf
> ;
flight 124954 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124954/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 36a93b0c2f8c08be8ba2041bcb24bb42d271deac
baseline version:
freebsd
flight 124983 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124983/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
flight 124930 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 124203
Tests which
This run is configured for baseline tests only.
flight 74935 qemu-upstream-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On Mon, Jul 2, 2018 at 5:14 AM Razvan Cojocaru
wrote:
>
> On 07/02/2018 09:34 AM, Jan Beulich wrote:
> On 29.06.18 at 18:39, wrote:
> >> On 06/29/2018 06:38 PM, Jan Beulich wrote:
> >> On 28.06.18 at 15:00, wrote:
> @@ -4666,6 +4667,23 @@ static int do_altp2m_op(
> }
On 04/07/18 11:16, Jan Beulich wrote:
On 03.07.18 at 22:55, wrote:
>> From: Sergey Dyasli
>>
>> This hypercall allows the toolstack to present one combined CPUID and MSR
>> policy for a domain, which can be audited in one go by Xen, which is
>> necessary
>> for correctness of the auditing.
flight 124971 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124971/
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
flight 124924 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken in 124877
On 04/07/18 10:43, Jan Beulich wrote:
> Oh, here we go - the title doesn't suggest this is about CPUID as well.
>
On 03.07.18 at 22:55, wrote:
>> Extend the xen-cpuid utility to be able to dump the system policies. An
>> example output is:
>>
>> Xen reports there are maximum 113 leaves
On 04/07/18 10:22, Jan Beulich wrote:
On 03.07.18 at 22:55, wrote:
>> This is mainly prep work for the following patch, but this specific
>> abstraction is also specifically useful for the future auditing logic.
>>
>> Not all of msr_vcpu_policy will be interesting from a domain building
>>
On 04/07/18 10:16, Jan Beulich wrote:
>
>> @@ -325,6 +325,13 @@ typedef struct xen_cpuid_leaf {
>> } xen_cpuid_leaf_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_cpuid_leaf_t);
>>
>> +typedef struct xen_msr_entry {
>> +uint32_t idx;
>> +uint32_t flags; /* Reserved MBZ. */
> ... it remains unclear
On Wed, Jul 04, 2018 at 05:30:54PM +0100, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [PATCH v2 1/8] xen: calculate XEN_BUILD_TIME using
> XEN_BUILD_DATE value"):
> > On Wed, Jul 04, 2018 at 04:41:30PM +0100, Ian Jackson wrote:
> > > I don't have a FreeBSD host to hand to test, CC'ing Roger.
>
On Wed, Jul 04, 2018 at 09:34:09AM -0600, Jan Beulich wrote:
> >>> On 04.07.18 at 16:25, wrote:
> > On Thu, Jun 28, 2018 at 07:51:52AM -0600, Jan Beulich wrote:
> >> >>> On 19.06.18 at 16:35, wrote:
> >> > Then rename xen.mb.efi to xen.efi and drop all related
> >> > differentiators in the code.
On 04/07/18 10:01, Jan Beulich wrote:
On 03.07.18 at 22:55, wrote:
>> --- a/xen/common/libx86/cpuid.c
>> +++ b/xen/common/libx86/cpuid.c
>> @@ -34,6 +34,100 @@ const uint32_t *x86_cpuid_lookup_deep_deps(uint32_t
>> feature)
>> }
>>
>> /*
>> + * Copy a single cpuid_leaf into a provided
> On Jul 4, 2018, at 4:38 PM, Jan Beulich wrote:
>
On 04.07.18 at 16:05, wrote:
>>> On Jul 2, 2018, at 7:34 AM, Jan Beulich wrote:
>> On 29.06.18 at 18:39, wrote:
On 06/29/2018 06:38 PM, Jan Beulich wrote:
On 28.06.18 at 15:00, wrote:
>> @@ -4666,6 +4667,23 @@
On Wed, Jul 04, 2018 at 09:27:43AM -0600, Jan Beulich wrote:
> >>> On 04.07.18 at 16:01, wrote:
> > On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote:
> >> >>> On 19.06.18 at 16:35, wrote:
> >> >- DOS stub code reduction; experiments showed that DOS stub code size
> >> >
Daniel Kiper writes ("Re: [PATCH v2 1/8] xen: calculate XEN_BUILD_TIME using
XEN_BUILD_DATE value"):
> On Wed, Jul 04, 2018 at 04:41:30PM +0100, Ian Jackson wrote:
> > I don't have a FreeBSD host to hand to test, CC'ing Roger.
>
> This is not the date command problem. This is more related to
>
Hi Stefano,
On 03/07/18 23:16, Stefano Stabellini wrote:
On Tue, 3 Jul 2018, Julien Grall wrote:
Hi Stefano,
On 02/07/18 22:31, Stefano Stabellini wrote:
On Thu, 14 Jun 2018, Julien Grall wrote:
On 13/06/18 23:15, Stefano Stabellini wrote:
+
+- cpus (optional)
+
+A string specifying
Ian Jackson writes ("[PATCH for-4.12 v2 0/8] tools: Depriv fd checking,
internal fd access"):
> This series provides the support in xen.git for auditing whether qemu
> file descriptors are deprivileged, as expected with libxl
> dm_restrict=1.
These were all acked.
However, on rebasing to
On 04/07/18 09:51, Jan Beulich wrote:
On 04.07.18 at 10:42, wrote:
>> On Tue, Jul 03, 2018 at 09:55:19PM +0100, Andrew Cooper wrote:
>>> --- a/xen/include/public/arch-x86/xen.h
>>> +++ b/xen/include/public/arch-x86/xen.h
>>> @@ -314,6 +314,17 @@ struct xen_arch_domainconfig {
>>> #define
flight 124944 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124920
version targeted for
Jason Andryuk writes ("Re: [Xen-devel] [PATCH 3/3] process docs: Final
branching checklist steps"):
> On Mon, Jun 25, 2018 at 10:53 AM, Ian Jackson
> wrote:
> > +Set off a manual osstest run, since the osstest cr-for-branches change
> > +will take a while to take effect:
> > + ssh
On Wed, Jul 04, 2018 at 04:41:30PM +0100, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [PATCH v2 1/8] xen: calculate XEN_BUILD_TIME using
> XEN_BUILD_DATE value"):
> > On Wed, Jul 04, 2018 at 02:58:17PM +0100, Ian Jackson wrote:
> > > export XEN_BUILD_POSIX_TIME ?= $(shell echo
> > >
On Thursday, 5 July 2018 1:47:27 AM AEST Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> > I seem to recall saying that even if we agreed that moving to
On Wed, Jul 04, 2018 at 04:41:30PM +0100, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [PATCH v2 1/8] xen: calculate XEN_BUILD_TIME using
> XEN_BUILD_DATE value"):
> > On Wed, Jul 04, 2018 at 02:58:17PM +0100, Ian Jackson wrote:
> > > export XEN_BUILD_POSIX_TIME ?= $(shell echo
> > >
On Thursday, 5 July 2018 1:26:16 AM AEST George Dunlap wrote:
> > On Jul 3, 2018, at 11:07 AM, Roger Pau Monné
> > wrote:
> >
> > On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
> >
> >> We then had a discussion around why the positive benefits didn't
> >> materialize:
* Andrew and
>>> On 04.07.18 at 16:44, wrote:
> xen-tools/libs.h currently contains a shared BUILD_BUG_ON() implementation and
> is used by some tools. Extend this to include ARRAY_SIZE and clean up all the
> opencoding.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 04/07/18 09:42, Jan Beulich wrote:
>
>> --- /dev/null
>> +++ b/xen/common/libx86/libx86-private.h
>> @@ -0,0 +1,42 @@
>> +#ifndef XEN_LIBX86_PRIVATE_H
>> +#define XEN_LIBX86_PRIVATE_H
>> +
>> +#ifdef __XEN__
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#else
>> +
>>
Andrew Cooper writes ("[PATCH] tools: Move ARRAY_SIZE() into xen-tools/libs.h"):
> xen-tools/libs.h currently contains a shared BUILD_BUG_ON() implementation and
> is used by some tools. Extend this to include ARRAY_SIZE and clean up all the
> opencoding.
Wow. Thank you.
Acked-by: Ian Jackson
George Dunlap writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> I seem to recall saying that even if we agreed that moving to continuous
> delivery was a goal we wanted to pursue, we would
Daniel Kiper writes ("Re: [PATCH v2 1/8] xen: calculate XEN_BUILD_TIME using
XEN_BUILD_DATE value"):
> On Wed, Jul 04, 2018 at 02:58:17PM +0100, Ian Jackson wrote:
> > export XEN_BUILD_POSIX_TIME ?= $(shell echo $${SOURCE_DATE_EPOCH-date +%s})
>
> OK, but what if SOURCE_DATE_EPOCH is not
Nothing exciting here, patches created mechanically
(common after soft freeze).
Philippe Mathieu-Daudé (8):
qobject: Catch another straggler for use of qdict_put_str()
error: Remove NULL checks on error_propagate() calls
crypto: Remove useless casts
xen: Remove useless casts
Patch created mechanically by rerunning:
$ spatch --sp-file scripts/coccinelle/typecast.cocci \
--macro-file scripts/cocci-macro-file.h \
--dir . --in-place
Signed-off-by: Philippe Mathieu-Daudé
---
hw/xen/xen_pt_config_init.c | 2 +-
1 file changed, 1 insertion(+),
>>> On 04.07.18 at 16:05, wrote:
>> On Jul 2, 2018, at 7:34 AM, Jan Beulich wrote:
> On 29.06.18 at 18:39, wrote:
>>> On 06/29/2018 06:38 PM, Jan Beulich wrote:
>>> On 28.06.18 at 15:00, wrote:
> @@ -4666,6 +4667,23 @@ static int do_altp2m_op(
> }
> break;
>>> On 04.07.18 at 15:20, wrote:
> On Wed, Jul 04, 2018 at 03:20:45PM +0300, Adrian POP wrote:
>> On Fri, Jun 29, 2018 at 09:38:58AM -0600, Jan Beulich wrote:
>> > > --- a/xen/arch/x86/mm/mem_access.c
>> > > +++ b/xen/arch/x86/mm/mem_access.c
>> > > @@ -32,17 +32,10 @@
>> > >
>> > > #include
>>> On 04.07.18 at 16:25, wrote:
> On Thu, Jun 28, 2018 at 07:51:52AM -0600, Jan Beulich wrote:
>> >>> On 19.06.18 at 16:35, wrote:
>> > Then rename xen.mb.efi to xen.efi and drop all related
>> > differentiators in the code.
>>
>> For this you'll first of all need to convince me that the binary
>>> On 04.07.18 at 16:01, wrote:
> On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote:
>> >>> On 19.06.18 at 16:35, wrote:
>> >- DOS stub code reduction; experiments showed that DOS stub code size
>> > cannot be changed due to some bugs in applications playing with PE
>> >
> On Jul 3, 2018, at 11:07 AM, Roger Pau Monné wrote:
>
> On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
>> We then had a discussion around why the positive benefits didn't materialize:
>> * Andrew and a few other believe that the model isn't broken, but that the
>> issue is with
xen-tools/libs.h currently contains a shared BUILD_BUG_ON() implementation and
is used by some tools. Extend this to include ARRAY_SIZE and clean up all the
opencoding.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Ian Jackson
CC: Wei Liu
---
tools/include/xen-tools/libs.h |
On Thu, Jun 28, 2018 at 07:51:52AM -0600, Jan Beulich wrote:
> >>> On 19.06.18 at 16:35, wrote:
> > Then rename xen.mb.efi to xen.efi and drop all related
> > differentiators in the code.
>
> For this you'll first of all need to convince me that the binary you build is
> a drop-in replacement for
On Wed, Jul 04, 2018 at 03:14:49PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH] osstest: limit FreeBSD jobs to hardware
> booting in BIOS mode"):
> > There's no support yet in osstest to install FreeBSD from UEFI, so for
> > the time being limit the FreeBSD jobs to boxes booting
Roger Pau Monne writes ("[PATCH] osstest: limit FreeBSD jobs to hardware
booting in BIOS mode"):
> There's no support yet in osstest to install FreeBSD from UEFI, so for
> the time being limit the FreeBSD jobs to boxes booting with legacy
> BIOS.
Surely this can't be right, because it only
flight 124921 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124921/
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 Jul 2, 2018, at 7:34 AM, Jan Beulich wrote:
>
On 29.06.18 at 18:39, wrote:
>> On 06/29/2018 06:38 PM, Jan Beulich wrote:
>> On 28.06.18 at 15:00, wrote:
@@ -4666,6 +4667,23 @@ static int do_altp2m_op(
}
break;
+case
There's no support yet in osstest to install FreeBSD from UEFI, so for
the time being limit the FreeBSD jobs to boxes booting with legacy
BIOS.
Signed-off-by: Roger Pau Monné
---
Note that this patch depends on Ian Jackson's resource allocation
series.
---
make-freebsd-flight | 4 ++--
1 file
On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote:
> >>> On 19.06.18 at 16:35, wrote:
> > Not done:
> >- ASM PE header conversion to C; not feasible,
>
> Hmm. As long as you can convince Andrew to give you an ack, I
> won't veto it. But I continue to dislike it, and hence I don't
>
Daniel Kiper writes ("Re: [PATCH v2 1/8] xen: calculate XEN_BUILD_TIME using
XEN_BUILD_DATE value"):
> Well, this complicates situation further and it seems to me that
> sed-ery cannot be sufficient. Anyway, I will take a look how to
> solve that.
Our other current host OS is FreeBSD. FreeBSD's
>>> On 04.07.18 at 14:03, wrote:
> On 04/07/18 09:21, Jan Beulich wrote:
> On 03.07.18 at 22:55, wrote:
>>> --- a/tools/include/Makefile
>>> +++ b/tools/include/Makefile
>>> @@ -21,6 +21,9 @@ xen/.dir:
>>> ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h)
>>>
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 -
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 5 +
xen/arch/x86/hvm/i8254.c | 2 +-
xen/arch/x86/hvm/irq.c | 6 +++---
xen/arch/x86/hvm/mtrr.c| 2 +-
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Change return of the save_one func to return hvm_save_entry.
Note: This patch is based on Roger Pau Monne's series[1]
---
xen/arch/x86/hvm/mtrr.c | 75
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V8:
- Change return of the save_one func to return hvm_save_entry
- Move continue out of on func
- Remove #define CONTINUE.
---
xen/arch/x86/hvm/hvm.c | 211
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V7:
- Moved the init of ctxt->count to hvm_save_cpu_msrs_one()
---
xen/arch/x86/hvm/hvm.c | 101 +++--
1 file changed, 55 insertions(+), 46
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Change return of the save_one func to return hvm_save_entry.
---
xen/arch/x86/hvm/hvm.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git
This patch is focused on moving the for loop to the caller so
now we can save info for a single vcpu instance with the save_one
handlers.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/save.c | 141 +---
1 file changed, 111 insertions(+), 30
Hi all,
This patch series addresses the ideea of saving data from a single vcpu
instance.
First it starts by adding *save_one functions, then it introduces a handler for
the
new save_one* funcs and makes use of it in the hvm_save and hvm_save_one funcs.
The final 2 patches are used for clean
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/viridian.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 694eae6..1e87cd6 100644
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Move continue out of save_one func.
---
xen/arch/x86/hvm/hvm.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Change return of the save_one func to return hvm_save_entry.
---
xen/arch/x86/cpu/mcheck/vmce.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff
This patch removes the redundant save functions and renames the
save_one* to save. It then changes the domain param to vcpu in the save
funcs.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Add enum return type for save funcs
---
xen/arch/x86/cpu/mcheck/vmce.c | 24 +++--
Signed-off-by: Alexandru Isaila
---
Changes since V8:
- Add comment for the handler return values.
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 +
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 6 +-
xen/arch/x86/hvm/i8254.c | 2 +-
xen/arch/x86/hvm/irq.c
On Wed, Jul 04, 2018 at 03:20:45PM +0300, Adrian POP wrote:
> On Fri, Jun 29, 2018 at 09:38:58AM -0600, Jan Beulich wrote:
> > > --- a/xen/arch/x86/mm/mem_access.c
> > > +++ b/xen/arch/x86/mm/mem_access.c
> > > @@ -32,17 +32,10 @@
> > >
> > > #include "mm-locks.h"
> > >
> > > -/*
> > > - *
Hello,
On Mon, Jul 02, 2018 at 12:01:01PM +0100, Julien Grall wrote:
> Hi,
>
> On 06/28/2018 02:00 PM, Adrian Pop wrote:
> > diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> > index ae2686ffa2..ba9e50e7f6 100644
> > --- a/xen/arch/arm/mem_access.c
> > +++
On Fri, Jun 29, 2018 at 09:38:58AM -0600, Jan Beulich wrote:
> >>> On 28.06.18 at 15:00, wrote:
> > @@ -4666,6 +4667,23 @@ static int do_altp2m_op(
> > }
> > break;
> >
> > +case HVMOP_altp2m_get_mem_access:
> > +if ( a.u.mem_access.pad )
> > +rc =
On Mon, Jun 25, 2018 at 03:00:07PM +0100, Andrew Cooper wrote:
> On 25/06/18 14:54, Jan Beulich wrote:
> On 19.06.18 at 16:35, wrote:
> >> We need the POSIX time to properly fill the TimeDateStamp field in the PE
> >> header.
> >>
> >> Additionally, realign the variables assignment in
On Mon, Jun 25, 2018 at 07:48:34AM -0600, Jan Beulich wrote:
> >>> On 19.06.18 at 16:35, wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -9,7 +9,7 @@ export XEN_FULLVERSION =
> > $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
> > export XEN_WHOAMI ?= $(USER)
> > export
On 04/07/18 09:21, Jan Beulich wrote:
On 03.07.18 at 22:55, wrote:
>> --- a/tools/include/Makefile
>> +++ b/tools/include/Makefile
>> @@ -21,6 +21,9 @@ xen/.dir:
>> ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h)
>> xen/libelf/
>> ln -s ../xen-foreign
On Wed, Jul 04, 2018 at 11:59:20AM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [freebsd-master test] 124935: trouble:
> blocked/broken"):
> > I will send some patches to fix that in a moment.
>
> With those patches, I think adding this "flag" to an appropriate
> hostflags
On Tue, Jul 03, 2018 at 03:48:22PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3.1] libxl: Design of an async API to issue
> QMP commands to QEMU"):
> > All the functions will be implemented in later patches.
>
> Thanks, this really makes things clearer for me.
>
> > What do you
Ian Jackson writes ("Re: [Xen-devel] [freebsd-master test] 124935: trouble:
blocked/broken"):
> I will send some patches to fix that in a moment.
With those patches, I think adding this "flag" to an appropriate
hostflags runvar will DTRT:
PropEq:Firmware:bios:bios
But I haven't tested that.
Now you can pass another :-separated argument, the default value to
use if none is specified.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
Osstest/ResourceCondition/PropCompareBase.pm | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
We need to take these from the config too.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
Osstest/ResourceCondition/PropCompareBase.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/Osstest/ResourceCondition/PropCompareBase.pm
b/Osstest/ResourceCondition/PropCompareBase.pm
index
This is going to make defaulting etc. a bit easier.
No functional change.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
Osstest/ResourceCondition/PropCompareBase.pm | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
Roger Pau Monné writes ("Re: [Xen-devel] [freebsd-master test] 124935: trouble:
blocked/broken"):
> This failure is caused because the host is set to boot from UEFI, and
> there's no logic yet in osstest to install FreeBSD from UEFI.
Oh. (Please disregard my other mail.)
> Is there anyway to
On Wed, Jul 04, 2018 at 01:57:58AM -0600, Jan Beulich wrote:
> >>> On 03.07.18 at 18:02, wrote:
> > On Thu, Jun 28, 2018 at 11:35:24PM -0600, Jan Beulich wrote:
> >> >>> Roger Pau Monne 06/28/18 5:38 PM >>>
> >> >lld (the llvm linker) has some issues with Xen linker script. It
> >> >doesn't
On Wed, Jul 04, 2018 at 11:30:42AM +0100, Ian Jackson wrote:
> osstest service owner writes ("[freebsd-master test] 124935: trouble:
> blocked/broken"):
> > flight 124935 freebsd-master real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/124935/
> >
> > Failures and problems with
All,
this is supposed to go out in about 3 weeks time. Please point out backport
candidates you find missing from its staging branch, but which you consider
relevant.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 04/07/18 09:17, Jan Beulich wrote:
On 03.07.18 at 22:55, wrote:
>> Some open questions:
>>
>> * The position of libx86 in the source tree. It probably doesn't want to
>> live in its current location.
> So did you intentionally decide against ...
>
>> .gitignore
On 04/07/18 11:18, Wei Liu wrote:
> On Tue, Jul 03, 2018 at 09:55:26PM +0100, Andrew Cooper wrote:
>> From: Sergey Dyasli
>>
>> This hypercall allows the toolstack to present one combined CPUID and MSR
>> policy for a domain, which can be audited in one go by Xen, which is
>> necessary
>> for
osstest service owner writes ("[freebsd-master test] 124935: trouble:
blocked/broken"):
> flight 124935 freebsd-master real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/124935/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including
On Tue, Jul 03, 2018 at 09:55:26PM +0100, Andrew Cooper wrote:
> From: Sergey Dyasli
>
> This hypercall allows the toolstack to present one combined CPUID and MSR
> policy for a domain, which can be audited in one go by Xen, which is necessary
> for correctness of the auditing.
>
> A stub
flight 74934 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74934/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail blocked
in 74915
flight 124960 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124960/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen b4ac4bc410222d221dc46a74ac71efaa7b32d57c
baseline version:
xen
>>> On 03.07.18 at 22:55, wrote:
> @@ -47,6 +48,17 @@ static inline bool test_bit(unsigned int bit, const void
> *vaddr)
> 0; \
> })
>
> +/* memcpy(), but with copy_from_guest_offset()'s API */
> +#define copy_from_buffer_offset(dst, src,
>>> On 03.07.18 at 22:55, wrote:
> From: Sergey Dyasli
>
> This finally (after literally years of work!) marks the point where the
> toolstack can ask the hypervisor for the current CPUID configuration of a
> specific domain.
>
> Also extend xen-cpuid's --policy mode to be able to take a domid
Oh, here we go - the title doesn't suggest this is about CPUID as well.
>>> On 03.07.18 at 22:55, wrote:
> Extend the xen-cpuid utility to be able to dump the system policies. An
> example output is:
>
> Xen reports there are maximum 113 leaves and 3 MSRs
> Raw policy: 93 leaves, 3
> >> >> > +#define IPT_CAP(_n, _l, _r, _m) \
> >> >> > +[IPT_CAP_ ## _n] = { .name = __stringify(_n), .leaf = _l, \
> >> >> > +.reg = _r, .mask = _m }
> >> >> > +
> >> >> > +static struct ipt_cap_desc {
> >> >> > +const char*name;
> >> >> > +
> >> >> > @@ -40,3 +42,102 @@ static int __init parse_ipt_params(const
> >> >> > char
> >> >> > +static inline void ipt_save_msr(struct ipt_ctx *ctx, unsigned
> >> >> > +int
> >> >> > +addr_range) {
> >> >> > +unsigned int i;
> >> >> > +
> >> >> > +rdmsrl(MSR_IA32_RTIT_STATUS,
This run is configured for baseline tests only.
flight 74933 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74933/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aa4240edff41034d709938a15b42cf4fd3214386
baseline
>>> On 03.07.18 at 22:55, wrote:
> This is mainly prep work for the following patch, but this specific
> abstraction is also specifically useful for the future auditing logic.
>
> Not all of msr_vcpu_policy will be interesting from a domain building
> perspective, but some soon-to-appear fields
flight 124914 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124914/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-xsm 1
1 - 100 of 126 matches
Mail list logo