On Tue, Jul 03, 2018 at 09:55:15PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> This prevents having to generate it inside the libxc folder.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey
On Tue, Jul 03, 2018 at 09:55:16PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey Dyasli
> CC: Ian Jackson
> ---
> too
Hi,
On 03/07/2018 22:30, Stefano Stabellini wrote:
On Tue, 3 Jul 2018, Julien Grall wrote:
Hi,
On 02/07/18 22:38, Stefano Stabellini wrote:
On Mon, 2 Jul 2018, Julien Grall wrote:
Hi,
On 02/07/2018 21:37, Stefano Stabellini wrote:
On Fri, 15 Jun 2018, Julien Grall wrote:
Hi Stefano,
On 0
On Tue, Jul 03, 2018 at 09:55:18PM +0100, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-d
On Tue, Jul 03, 2018 at 09:55:17PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
> individual copies from the hypervisor and libxc respectively.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
>
flight 124913 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124913/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 124801
test-amd64-amd64-qem
On Tue, Jul 03, 2018 at 05:53:44PM +0100, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH 1/3] osstest: remove duplicate
> set_freebsd_runvars"):
> > On Tue, Jul 03, 2018 at 04:10:56PM +0100, Ian Jackson wrote:
> > > Roger Pau Monne writes ("[PATCH 1/3] osstest: remove duplicate
> > > se
>>> 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 understand '||' in assert expressions:
>> >
>> >ld-melf_x86_64_fbsd -T
On Tue, Jul 03, 2018 at 05:56:51PM +0100, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH 3/3] osstest: add FreeBSD Xen build job"):
> > On Tue, Jul 03, 2018 at 04:22:45PM +0100, Ian Jackson wrote:
> > > This is quite ugly. sg-run-job normally tries to be a bit more
> > > abstract. I'm n
>>> 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 | 2 +-
> tools/include/Makefi
>>> 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 xen/foreign
> ln -sf $(XEN_ROOT)/xen/include
This run is configured for baseline tests only.
flight 74932 xen-4.11-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow222 leak-check/
>>> On 03.07.18 at 22:55, wrote:
> From: Roger Pau Monné
>
> This prevents having to generate it inside the libxc folder.
And this is useful / desirable / necessary because of what?
> RFC - I'm not sure a parallel build of Xen and the tools works.
I'm pretty sure it won't with this approach.
>>> On 03.07.18 at 22:55, wrote:
> From: Roger Pau Monné
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
This is all fine with me (subject to path name adjustments), but the description
is too short. I'd expect this to at least make clear that this
On Tue, Jul 03, 2018 at 09:55:19PM +0100, Andrew Cooper wrote:
> The serialised form is made up of the leaf, subleaf and data tuple. As this
> is the architectural form, it is expected not to change going forwards.
>
> x86_cpuid_copy_to_buffer() is implemented using Xen's regular copy_to_guest
>
>>> On 03.07.18 at 22:55, wrote:
> From: Roger Pau Monné
>
> Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
> individual copies from the hypervisor and libxc respectively.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC:
>>> On 03.07.18 at 22:55, wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Same as for the earlier patch: Please make clear here that this is for
convenience only.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:
> >> > @@ -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, ctx->status);
> >> > +rdmsrl(MSR_IA32_RTIT_OUTPU
> >> > +#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;
> >> > +unsigned int leaf;
> >>
>>> 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 XEN_ACPI_GPE0_CPUHP_BIT 2
>> #endif
>>
>>> 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 xen_cpuid_leaf_t buffer,
> + * performing boundar
>>> On 04.07.18 at 10:48, wrote:
>> >> > @@ -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, ctx->status)
>>> On 04.07.18 at 10:48, wrote:
>> >> > +#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*na
>>> On 03.07.18 at 22:55, wrote:
> From: Roger Pau Monné
>
> As with CPUID, the an architectural form is used for representing the MSR
Stray "the".
Apart from that same remark(s) as for the respective CPUID change,
plus ...
> @@ -325,6 +325,13 @@ typedef struct xen_cpuid_leaf {
> } xen_cpuid
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 build
>>> 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 w
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 v
> >> >> > @@ -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, ctx->status);
> >> >> > +#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;
> >> >> > +uns
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 MSRs
>>> 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
>>> 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, i
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 1f64
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
test-amd64-amd
>>> 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.
>
> A stub x86_policies_are_compatible() funct
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 x86_po
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 tes
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 cor
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
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
https://lists.xenproj
>>> On 04.07.18 at 12:40, wrote:
> On 04/07/18 09:17, Jan Beulich wrote:
>> Personally I'd favor the top level variants, as that makes
>> sufficiently clear that the code is neither specific to the hypervisor
>> nor specific to the tools.
>
> That's the concern I've got with the top level variant
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 tes
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 under
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 pr
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 a/Osstest/ResourceCondition/PropCompareBase.pm
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 a/Osstest/ResourceCondition
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.
I
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
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 run
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 xen/for
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 XEN_D
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 xen/Mak
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 = -EINV
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
> > +++ b/xen/arch/arm/mem_ac
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"
> > >
> > > -/*
> > > - * Get
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
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 a/xen/arch/x86/
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 +++--
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 a/xen/arch/x86
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 dele
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 up.
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 del
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 ++
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 +-
xen/arch/x86/hv
>>> 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)
>>> xen/lib
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 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
> c
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 ch
> 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 HVMOP_altp2m_get_
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
test-amd
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 touche
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 wi
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 02:58:17PM +0100, Ian Jackson wrote:
> 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 ho
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 |
flight 124963 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124963/
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 1
> 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
>>> 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 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 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 "m
>>> 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;
>>
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
tests/bios-t
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(+), 1
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 defined?
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 s
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
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
>> +
>> +#in
>>> 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 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 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
> > > $${S
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 c
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
> > > $${S
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 osstest.test-
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 testi
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 XEN
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 current
1 - 100 of 130 matches
Mail list logo
