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
flight 125285 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 123554
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, July 17, 2018 5:28 PM
>
> On 04/06/18 14:59, Andrew Cooper wrote:
> > c/s 4f36452b63 introduced a write to %dr6 in the #DB intercept case, but
> the
> > guests debug registers may be lazy at this point, at which point the
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:44 PM
>
> While not strictly necessary, change the VMX initialization logic to
> update the function table in start_vmx() from NULL rather than to NULL,
> to make more obvious that we won't ever change an already
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:26 PM
>
> Commit a1b1572833 ("VMX: add VMFUNC leaf 0 (EPTP switching) to
> emulator") needlessly introduced it, and no user has appeared since.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:25 PM
>
> From: Suravee Suthikulpanit
>
> This patch modifies the hvm_funcs.virtual_intr_delivery_enabled()
> to become a bool variable as VMX does and SVM will simply return a
> static value.
>
> Signed-off-by:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:24 PM
>
> Instead of checking hvm_tsc_scaling_supported inside the hook function,
> install the hook only when setting state such that said predicate
> becomes true.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 11, 2018 9:23 PM
>
> Three of the four hooks are not exposed outside of vmx.c, and all of
> them have only a single possible non-NULL value. So there's no reason to
> use hooks here - a simple set of flag indicators is
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, July 18, 2018 5:39 PM
>
> >>> On 18.07.18 at 11:36, wrote:
> > On Mon, Jul 16, 2018 at 10:46:11AM -0600, Jan Beulich wrote:
> >> For a reason that I can't explain, it is only the shim build that fails
> >> for me with an older gcc
On Wed, Jul 4, 2018 at 3:41 AM, Jan Beulich wrote:
> 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.
>
Marek's patches below are each straightforward and enable clean
flight 125276 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken in 125165
build-armhf-libvirt
On Wed, Jul 18, 2018 at 02:21:53AM -0600, Jan Beulich wrote:
> Reportedly Intel CPUs which can't broadcast #MC to all targeted
> cores/threads because some have CR4.MCE clear will shut down. Therefore
> we want to keep CR4.MCE enabled when offlining a CPU, and we need to
> bring up all CPUs in
When cross-compiling for x86 with gcc 8.1, the generation of
compat/callback.i fails due to the redefinition of __OBJECT_FILE__ and
__OBJECT_LABEL__ variables on the compiler command line during the shim
build:
| : error: "__OBJECT_FILE__" redefined [-Werror]
| : note: this is the location of the
gcc-8.1 complains:
| xentop.c: In function 'print':
| xentop.c:304:4: error: 'vwprintw' is deprecated
[-Werror=deprecated-declarations]
| vwprintw(stdscr, (curses_str_t)fmt, args);
| ^~~~
vw_printw (note the underscore) is a non-deprecated alternative.
Signed-off-by: Christopher
On certain occasions platform might generate NMIs during kexec transition.
It could be cascades of NMIs following the first one, escalated Master
Aborts following IOMMU shutdown on the transition itself, etc.
Purgatory code is now unprepared for any sort of exception or interrupt
handling
flight 125350 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125350/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
> On Jul 18, 2018, at 1:01 PM, Stefano Stabellini
> wrote:
>
> On Wed, 18 Jul 2018, Jan Beulich wrote:
> On 17.07.18 at 22:29, wrote:
>>> On 07/07/2018 00:12, Stefano Stabellini wrote:
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for
flight 74985 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74985/
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 like
74953
flight 125341 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125341/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 125340 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125340/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
flight 125273 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125273/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 124797
On Tue, 17 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 07/07/2018 00:12, Stefano Stabellini wrote:
> > Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> > mechanism to allow for switching between Xen, Dom0, and any of the
> > initial DomU created from Xen alongside Dom0
It turns out that Xen has never enforced that a domain remain within the
xstate features advertised in CPUID.
The check of new_bv against xfeature_mask ensures that a domain stays within
the set of features that Xen has enabled in hardware (and therefore isn't a
security problem), but this does
Andrew Cooper (2):
x86/xstate: Use a guests CPUID policy, rather than allowing all features
x86/xstate: Make errors in xstate calculations more obvious by crashing the
domain
xen/arch/x86/domctl.c| 2 +-
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/xstate.c| 30
If new_bv which exceeds xfeature_mask, then something is broken with the CPUID
policy derivation or auditing logic. If hardware rejects new_bv, then
something is broken with Xen's xstate logic.
In both cases, crash the domain with an obvious error message, to help
highlight the issues.
On Tue, 17 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 17/07/2018 21:05, Stefano Stabellini wrote:
> > On Mon, 9 Jul 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 07/07/18 00:11, Stefano Stabellini wrote:
> > > > Introduce an is_console option to allow certain classes of domUs to use
flight 125271 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125271/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183
Tests which did not
On Wed, 18 Jul 2018, Jan Beulich wrote:
> >>> On 17.07.18 at 22:29, wrote:
> > On 07/07/2018 00:12, Stefano Stabellini wrote:
> >> Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> >> mechanism to allow for switching between Xen, Dom0, and any of the
> >> initial DomU created
Hi Jan,
On 18/07/18 08:12, Jan Beulich wrote:
On 17.07.18 at 22:29, wrote:
On 07/07/2018 00:12, Stefano Stabellini wrote:
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen
On Wed, 18 Jul 2018, Jan Beulich wrote:
> >>> On 17.07.18 at 18:43, wrote:
> > On Tue, 17 Jul 2018, Jan Beulich wrote:
> >> >>> On 16.07.18 at 23:55, wrote:
> >> > On Mon, 16 Jul 2018, Jan Beulich wrote:
> >> >> >>> On 07.07.18 at 01:12, wrote:
> >> >> > @@ -389,29 +392,49 @@ static void
Hi Stefano,
On 13/07/18 21:54, Stefano Stabellini wrote:
On Thu, 12 Jul 2018, Julien Grall wrote:
Hi,
Would it be possible to provide a branch with the patch applied? It would be
nice to have that for every version, so I can easily know on which version of
you are based and avoid spending
On Wed, Jul 18, 2018 at 05:16:50PM +0100, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH v4 9/9] osstest: add FreeBSD Xen build
> job"):
> > On Wed, Jul 18, 2018 at 04:18:05PM +0100, Ian Jackson wrote:
> > > The reason you want the osstest branch to be covered is that it is an
> > >
On 18/07/18 17:16, Jan Beulich wrote:
On 18.07.18 at 18:05, wrote:
>> On 18/07/18 15:48, Jan Beulich wrote:
>> On 18.07.18 at 14:30, wrote:
Backporting notes: This is safe in the restore case, but only back as far
as
the introduction of cpuid_policy infrastructure.
flight 125331 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125331/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
>>> On 18.07.18 at 18:05, wrote:
> On 18/07/18 15:48, Jan Beulich wrote:
> On 18.07.18 at 14:30, wrote:
>>> Backporting notes: This is safe in the restore case, but only back as far as
>>> the introduction of cpuid_policy infrastructure. Before then, a restore
>>> boolean needs to be pumbed
Roger Pau Monné writes ("Re: [PATCH v4 9/9] osstest: add FreeBSD Xen build
job"):
> On Wed, Jul 18, 2018 at 04:18:05PM +0100, Ian Jackson wrote:
> > The reason you want the osstest branch to be covered is that it is an
> > input to this job. There is no protection against an un-covered input
> >
On 18/07/18 15:48, Jan Beulich wrote:
On 18.07.18 at 14:30, wrote:
>> Backporting notes: This is safe in the restore case, but only back as far as
>> the introduction of cpuid_policy infrastructure. Before then, a restore
>> boolean needs to be pumbed down as well, and used to select
On Wed, Jul 18, 2018 at 04:18:05PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH v4 9/9] osstest: add FreeBSD Xen build job"):
> > Roger Pau Monne writes ("[PATCH v4 9/9] osstest: add FreeBSD Xen build
> > job"):
> > > To both the FreeBSD and the xen-unstable flights.
> >
> >
Wei Liu writes ("[PATCH v3] tools: fix dependency for ipxe and rombios"):
> It appears that the test in 01d631028 for ipxe's dependency on rombios
> is not good enough. Configuring with --disable-rombios doesn't disable
> ipxe.
Acked-by: Ian Jackson
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
It appears that the test in 01d631028 for ipxe's dependency on rombios
is not good enough. Configuring with --disable-rombios doesn't disable
ipxe.
Fix it by testing the dependency in AC_ARG_ENABLE and AC_ARG_WITH at
the same time.
Now we have four options for ipxe:
--enable-ipxe
Wei Liu writes ("[PATCH v2] tools: fix dependency for ipxe and rombios"):
> It appears that the test in 01d631028 for ipxe's dependency on rombios
> is not good enough. Configuring with --disable-rombios doesn't disable
> ipxe.
>
> Fix it by testing the dependency in AC_ARG_ENABLE and AC_ARG_WITH
On Wed, Jul 18, 2018 at 04:15:02PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v4 8/9] osstest: introduce a helper to create
> Xen build jobs"):
> > This is currently a non-functional change, since no new jobs are
> > added, and the existing ones should stay unchanged. Runvars of
It appears that the test in 01d631028 for ipxe's dependency on rombios
is not good enough. Configuring with --disable-rombios doesn't disable
ipxe.
Fix it by testing the dependency in AC_ARG_ENABLE and AC_ARG_WITH at
the same time.
Now we have four options for ipxe:
--enable-ipxe
> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila wrote:
>
> From: Isaila Alexandru
>
> This patch adds access rights for the NPT pages. The access rights are
> saved in a radix tree with the root saved in p2m_domain. The rights are
> manipulated through p2m_set_access()
> and p2m_get_access()
On Wed, Jul 18, 2018 at 08:41:30AM -0600, Jan Beulich wrote:
> >>> On 18.07.18 at 12:27, wrote:
> > So that an ELF binary with support for EFI services will be built when
> > the compiler supports the MS ABI, regardless of the linker support for
> > PE.
> >
> > Signed-off-by: Roger Pau Monné
>
Ian Jackson writes ("Re: [PATCH v4 9/9] osstest: add FreeBSD Xen build job"):
> Roger Pau Monne writes ("[PATCH v4 9/9] osstest: add FreeBSD Xen build job"):
> > To both the FreeBSD and the xen-unstable flights.
>
> Please add this to the osstest flights too!
I should expand on this:
The reason
Roger Pau Monne writes ("[PATCH v4 8/9] osstest: introduce a helper to create
Xen build jobs"):
> This is currently a non-functional change, since no new jobs are
> added, and the existing ones should stay unchanged. Runvars of a
> xen-unstable flight are exactly the same.
Can you please extend
Roger Pau Monne writes ("[PATCH v4 9/9] osstest: add FreeBSD Xen build job"):
> To both the FreeBSD and the xen-unstable flights.
Please add this to the osstest flights too!
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Roger Pau Monne writes ("[PATCH v4 5/9] osstest: abstract code to create a
FreeBSD build job"):
> Into a helper. A diff of the runvars of flights generated with and
> without the patch show no differences.
Acked-by: Ian Jackson
___
Xen-devel mailing
flight 125317 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125317/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd bf65d05707104df94117a293327d797d71a0118d
baseline version:
freebsd
>>> On 18.07.18 at 16:47, wrote:
> On 18/07/18 10:19, Jan Beulich wrote:
> On 18.07.18 at 10:46, wrote:
>>> On 18/07/2018 09:33, Jan Beulich wrote:
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>>> On 18.07.18 at 14:30, wrote:
> If valid_xcr0() accepts a new_bv which exceeds xfeature_mask, then something
> is broken with the CPUID policiy derivation or auditing logic. If hardware
> rejects new_bv, then something is broken with Xen's xstate logic.
With what I've said about valid_xcr0()
>>> On 18.07.18 at 14:30, wrote:
> Backporting notes: This is safe in the restore case, but only back as far as
> the introduction of cpuid_policy infrastructure. Before then, a restore
> boolean needs to be pumbed down as well, and used to select between the
> hardware maximum value and calls
On 18/07/18 10:19, Jan Beulich wrote:
On 18.07.18 at 10:46, wrote:
>> On 18/07/2018 09:33, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/spec_ctrl.h
>>> +++ b/xen/include/asm-x86/spec_ctrl.h
>>> @@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
>>> #define OPT_XPTI_DOM0 0x01
>>> #define
>>> On 18.07.18 at 12:27, wrote:
> So that an ELF binary with support for EFI services will be built when
> the compiler supports the MS ABI, regardless of the linker support for
> PE.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Jan Beulich
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
>
On 18/07/18 15:30, Jan Beulich wrote:
>>> --- a/xen/include/xen/xmalloc.h
>>> +++ b/xen/include/xen/xmalloc.h
>>> @@ -42,6 +42,12 @@
>>> /* Free any of the above. */
>>> extern void xfree(void *);
>>>
>>> +/* Free an allocation, and zero the pointer to it. */
>>> +#define XFREE(p) do { \
>>> +
flight 125324 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125324/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
>>> On 18.07.18 at 13:37, wrote:
> On Wed, Jul 18, 2018 at 02:19:29AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/genapic/x2apic.c
>> +++ b/xen/arch/x86/genapic/x2apic.c
>> @@ -201,18 +201,21 @@ static int update_clusterinfo(
>> if ( !cluster_cpus_spare )
>>
>>> On 18.07.18 at 15:56, wrote:
> On Wed, Jul 18, 2018 at 02:21:53AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/mpparse.c
>> +++ b/xen/arch/x86/mpparse.c
>> @@ -68,19 +68,26 @@ physid_mask_t phys_cpu_present_map;
>>
>> void __init set_nr_cpu_ids(unsigned int max_cpus)
>> {
>> +
>>> On 18.07.18 at 15:48, wrote:
> On Wed, Jul 18, 2018 at 02:24:14AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -62,6 +62,9 @@ boolean_param("nosmp", opt_nosmp);
>> static unsigned int __initdata max_cpus;
>> integer_param("maxcpus", max_cpus);
On Wed, Jul 18, 2018 at 02:21:53AM -0600, Jan Beulich wrote:
> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -68,19 +68,26 @@ physid_mask_t phys_cpu_present_map;
>
> void __init set_nr_cpu_ids(unsigned int max_cpus)
> {
> + unsigned int tot_cpus = num_processors +
On Wed, Jul 18, 2018 at 02:24:14AM -0600, Jan Beulich wrote:
> Shared resources (L1 cache and TLB in particular) present a risk of
> information leak via side channels. Don't use hyperthreads in such
> cases, but allow independent control of their use at the same time.
>
> Signed-off-by: Jan
On Wed, Jul 18, 2018 at 01:02:38PM +0200, Olaf Hering wrote:
> The buildsystem of seabios always includes the current time and the
> hostname into the resulting binary. To avoid that, it is required to
> have a file '.version' in the toplevel directory of seabios-dir-remote.
> And it is required
On Wed, Jul 18, 2018 at 02:21:53AM -0600, Jan Beulich wrote:
> Reportedly Intel CPUs which can't broadcast #MC to all targeted
> cores/threads because some have CR4.MCE clear will shut down. Therefore
> we want to keep CR4.MCE enabled when offlining a CPU, and we need to
> bring up all CPUs in
On 18/07/18 14:35, Marek Marczykowski-Górecki wrote:
> Hi,
>
> Links here:
> https://blog.xenproject.org/2018/07/10/whats-new-in-the-xen-project-hypervisor-4-11/
> are broken - all points to https://www.google.com/url?q=
> ...
Thanks for the note. Should be corrected now.
Juergen
flight 125321 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125321/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
On 18/07/18 09:21, Jan Beulich wrote:
> Reportedly Intel CPUs which can't broadcast #MC to all targeted
> cores/threads because some have CR4.MCE clear will shut down. Therefore
> we want to keep CR4.MCE enabled when offlining a CPU, and we need to
> bring up all CPUs in order to be able to set
This run is configured for baseline tests only.
flight 74986 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74986/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d900d7c9857a676d9271a0ab499c12b379dc3652
baseline
On 18/07/18 09:20, Jan Beulich wrote:
> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
> the difference is not very big. The most relevant change (requiring some
> code restructuring) is that the topoext feature no longer means there is
> a valid CU ID.
>
> Take the
On 18/07/18 09:19, Jan Beulich wrote:
> In order to be able to service #MC on offlined CPUs, the GDT, IDT,
> stack, and per-CPU data (which includes the TSS) need to be kept
> allocated. They should only be freed upon CPU removal (which we
> currently don't support, so some code is becoming
Hi,
Links here:
https://blog.xenproject.org/2018/07/10/whats-new-in-the-xen-project-hypervisor-4-11/
are broken - all points to https://www.google.com/url?q=
...
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read
It turns out that Xen has never enforced that a domain remain within the
xstate features advertised in CPUID.
The check of new_bv against xfeature_mask ensures that a domain stays within
the set of features that Xen has enabled in hardware (and therefore isn't a
security problem), but this does
If valid_xcr0() accepts a new_bv which exceeds xfeature_mask, then something
is broken with the CPUID policiy derivation or auditing logic. If hardware
rejects new_bv, then something is broken with Xen's xstate logic.
In both cases, crash the domain with an obvious error message, to help
Andrew Cooper (2):
x86/xstate: Use the CPUID policy in valid_xcr0(), rather than allowing all
features
x86/xstate: Make errors in xstate calculations more obvious by crashing the
domain
xen/arch/x86/domctl.c| 2 +-
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/xstate.c
flight 125311 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125311/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, Jul 18, 2018 at 02:20:29AM -0600, Jan Beulich wrote:
> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
> the difference is not very big. The most relevant change (requiring some
> code restructuring) is that the topoext feature no longer means there is
> a valid CU
On Wed, Jul 18, 2018 at 02:19:29AM -0600, Jan Beulich wrote:
> --- a/xen/arch/x86/genapic/x2apic.c
> +++ b/xen/arch/x86/genapic/x2apic.c
> @@ -201,18 +201,21 @@ static int update_clusterinfo(
> if ( !cluster_cpus_spare )
> cluster_cpus_spare = xzalloc(cpumask_t);
>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-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:
The buildsystem of seabios always includes the current time and the
hostname into the resulting binary. To avoid that, it is required to
have a file '.version' in the toplevel directory of seabios-dir-remote.
And it is required to pass EXTRAVERSION= to make because its toplevel
Makefile does not
flight 125316 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125316/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen a60de1b9f80681859b845f35c1c0e191cddb0b01
baseline version:
xen
On Mon, Jul 16, 2018 at 06:04:30PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3.2] libxl: Design of an async API to issue
> QMP commands to QEMU"):
> > All the functions will be implemented in later patches.
> >
> > This patch includes the API that libxl can use to send QMP
So that an ELF binary with support for EFI services will be built when
the compiler supports the MS ABI, regardless of the linker support for
PE.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
Changes since v1:
- New in
So that it can be used by other components apart from the efi specific
code. By moving the detection code creating a dummy efi/disabled file
can be avoided.
This is required so that the conditional used to define the efi symbol
in the linker script can be removed and instead the definition of the
Hello,
The following patches started as a workaround to build Xen using lld
(the LLVM linker), but now patch #2 is an improvement of the build
system, thus allowing to create a multiboot2 capable ELF binary
requiring just a compiler that supports the MS ABI. Previously in order
to build a
flight 125307 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
Wei Liu writes ("Re: [PATCH] tools: fix dependency for ipxe and rombios"):
> On Tue, Jul 17, 2018 at 11:47:41AM +0100, Wei Liu wrote:
> > On Tue, Jul 17, 2018 at 11:18:59AM +0100, Ian Jackson wrote:
> > > So I'm sorry to say that I think the answer is to revert 01d631028a02
> > > and to replace it
On 07/18/2018 03:27 PM, Manish Jaggi wrote:
On 07/02/2018 07:51 PM, Roger Pau Monné wrote:
External Email
On Mon, Jul 02, 2018 at 04:16:05PM +0530, Manish Jaggi wrote:
Hi All,
PCI-PT and PCI config space emulation have been in discussion for
quite a
long time.
We had started some work
On Wed, Jul 18, 2018 at 11:58:21AM +0200, Olaf Hering wrote:
> Am Wed, 18 Jul 2018 10:39:31 +0100
> schrieb Wei Liu :
>
> > > + rm -f seabios-dir/.version
> > There is no need to rm -f here because the following > will clear its
> > content anyway.
>
>
> The content of seabios-dir is coming
Am Wed, 18 Jul 2018 10:39:31 +0100
schrieb Wei Liu :
> > + rm -f seabios-dir/.version
> There is no need to rm -f here because the following > will clear its
> content anyway.
The content of seabios-dir is coming from upstream, ".version" might be a
symlink. Thats why I added this rm
On 07/02/2018 07:51 PM, Roger Pau Monné wrote:
External Email
On Mon, Jul 02, 2018 at 04:16:05PM +0530, Manish Jaggi wrote:
Hi All,
PCI-PT and PCI config space emulation have been in discussion for quite a
long time.
We had started some work on this in past and in LEG-XEN but that didnt go
On Wed, Jul 18, 2018 at 11:44:40AM +0200, Olaf Hering wrote:
> On Tue, Jul 17, Wei Liu wrote:
>
> > No OVMF because it requires gcc 4.4 or later.
>
> Fine.
>
> > No seabios because it requires anonymous union initialisation
>
> It is required to build Xen like that (with a custom compiler from
On Tue, Jul 17, Wei Liu wrote:
> No OVMF because it requires gcc 4.4 or later.
Fine.
> No seabios because it requires anonymous union initialisation
It is required to build Xen like that (with a custom compiler from gcc48.rpm):
test -x "$(type -p gcc)" && CC=$_
test -x "$(type -p gcc-4.8)" &&
On Wed, Jul 18, 2018 at 03:35:20AM -0600, Jan Beulich wrote:
> >>> On 16.07.18 at 16:07, wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -163,11 +163,12 @@ EFI_LDFLAGS += --minor-image-version=$(XEN_SUBVERSION)
> > EFI_LDFLAGS += --major-os-version=2
On Wed, Jul 18, 2018 at 03:39:20AM -0600, Jan Beulich wrote:
> >>> On 18.07.18 at 11:36, wrote:
> > On Mon, Jul 16, 2018 at 10:46:11AM -0600, Jan Beulich wrote:
> >> For a reason that I can't explain, it is only the shim build that fails
> >> for me with an older gcc due to the compiler not
>>> On 18.07.18 at 11:36, wrote:
> On Mon, Jul 16, 2018 at 10:46:11AM -0600, Jan Beulich wrote:
>> For a reason that I can't explain, it is only the shim build that fails
>> for me with an older gcc due to the compiler not recognizing that
>> apparently uninitialized variables aren't really
On Fri, Jul 13, 2018 at 01:04:42PM +0200, Olaf Hering wrote:
> The buildsystem of seabios always includes the current time and the
> hostname into the resulting binary. To avoid that, it is required to
> have a file '.version' in the toplevel directory of seabios-dir-remote.
> And it is required
On Mon, Jul 16, 2018 at 10:46:11AM -0600, Jan Beulich wrote:
> For a reason that I can't explain, it is only the shim build that fails
> for me with an older gcc due to the compiler not recognizing that
> apparently uninitialized variables aren't really uninitialized. Pull out
> the assignments
>>> On 16.07.18 at 16:07, wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -163,10 +163,17 @@ EFI_LDFLAGS += --minor-image-version=$(XEN_SUBVERSION)
> EFI_LDFLAGS += --major-os-version=2 --minor-os-version=0
> EFI_LDFLAGS += --major-subsystem-version=2
On Mon, Jul 09, 2018 at 02:35:30AM -0600, Jan Beulich wrote:
> >>> On 05.07.18 at 12:44, wrote:
> > Both altp2m get/set memaccess functions use the struct
> > xen_hvm_altp2m_mem_access which has now dropped the `set' part and has
> > been renamed from xen_hvm_altp2m_set_mem_access.
> >
> >
1 - 100 of 129 matches
Mail list logo
