>>> 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 alongside Dom0 out of information provided
>
>>> On 17.07.18 at 22:03, wrote:
> Signed-off-by: Wei Liu
> ---
> No OVMF because it requires gcc 4.4 or later.
> No seabios because it requires anonymous union initialisation
This is unfortunate, and could perhaps be worked around by using the
alternative newer gcc-5 (iirc) that is being provid
>>> On 17.07.18 at 19:23, wrote:
> The vPMU logic isn't integrated into the CPUID policy logic (and still
> requires a fair amount of work before it can be).
>
> The ARCH_PERFMON leaf was previously copied into all policies, unilaterally
> overridden (to the same value in the general case) by the
flight 125259 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125259/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 125178
test-amd64-amd64-e
On Wed, Jul 18, 2018 at 01:25:22AM -0600, Jan Beulich wrote:
> >>> On 17.07.18 at 22:03, wrote:
> > Signed-off-by: Wei Liu
> > ---
> > No OVMF because it requires gcc 4.4 or later.
> > No seabios because it requires anonymous union initialisation
>
> This is unfortunate, and could perhaps be wor
I've been considering to add a respective command line option for
quite a long time, but never got around to. Now that the TLBleed
information is public[1], we're at a point where we not only want,
but need this, and where perhaps it needs to be the default on
affected systems. The first 4 patches
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
of schedule_cpu_switch
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 effectively dead
for the moment).
Signed-off-by: Jan
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 opportunity and convert wrongly plain int variables in
s
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 CR4.MCE in the first place.
The use of clear_in_
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 Beulich
---
v2: Rename option to "smt".
---
An option to avoid the up/down
Drop unnecessary casts and use bool in favor of bool_t.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Reviewed-by: Wei Liu
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -345,9 +345,9 @@ static inline int cpulist_scnprintf(char
typedef cpumask_t *cpumask_var_t;
1: x86: report use of PCID together with reporting XPTI status
2: x86/spec-ctrl: split reporting for PV and HVM guests
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 125302 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125302/
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
Putting them on separate lines was suggested before, and is going to
become necessary eventually anyway as things get added here. Split them
now, and put the respective pieces in CONFIG_* conditionals at the same
time.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/spec_ctrl.c
+++ b/
Signed-off-by: Jan Beulich
---
v2: Add CONFIG_PV conditional.
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -288,6 +288,12 @@ int pv_domain_initialise(struct domain *
return rc;
}
+bool __init xpti_pcid_enabled(void)
+{
+return use_invpcid && cpu_has_pcid &&
+
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 OPT_XPTI_DOMU 0x02
>
> +bool xpti_pcid_enabled(void);
This still should be inside an CON
On 18/07/2018 09:33, Jan Beulich wrote:
> Putting them on separate lines was suggested before, and is going to
> become necessary eventually anyway as things get added here. Split them
> now, and put the respective pieces in CONFIG_* conditionals at the same
> time.
>
> Signed-off-by: Jan Beulich
On Wed, Jul 18, 2018 at 02:19:29AM -0600, 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 c
On Wed, Jul 18, 2018 at 02:33:02AM -0600, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
> v2: Add CONFIG_PV conditional.
>
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -288,6 +288,12 @@ int pv_domain_initialise(struct domain *
> ret
On Wed, Jul 18, 2018 at 02:33:31AM -0600, Jan Beulich wrote:
> Putting them on separate lines was suggested before, and is going to
> become necessary eventually anyway as things get added here. Split them
> now, and put the respective pieces in CONFIG_* conditionals at the same
> time.
>
> Signed
On 18/07/18 10:18, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the per-CPU area to start out as all zeros, the
> CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
> the per-CPU cpupool pointer, cpupool_cpu_add()'
>>> On 16.07.18 at 18:56, wrote:
> On 16/07/18 17:46, 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.
>
> The only
>>> 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 OPT_XPTI_DOMU 0x02
>>
>> +bool xpti_pcid_enabled
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.
> >
> > Signed
>>> 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 --minor-subsystem-ve
>>> 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 --minor-os-version=0
> EFI_LDFLAGS += --major-subsystem-version=2 --minor-subsystem-ve
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 use
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 to
>>> 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 uninit
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 recogn
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 --minor-os-versi
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 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 18/07/18 08:29, Jan Beulich wrote:
On 17.07.18 at 19:23, wrote:
>> The vPMU logic isn't integrated into the CPUID policy logic (and still
>> requires a fair amount of work before it can be).
>>
>> The ARCH_PERFMON leaf was previously copied into all policies, unilaterally
>> overridden (to
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
f
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 comman
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 fr
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 o
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
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
On Wed, Jul 18, 2018 at 11:09:39AM +0100, Ian Jackson wrote:
> 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
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 multiboo
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 this
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
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 comma
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 e3f6
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 ta
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: qe
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);
> if
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 I
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 1
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 me
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
highligh
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
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 text.
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 effecti
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 opportu
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 v
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 CR4
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 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
_
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 orde
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 Beuli
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 to
On Wed, Jul 18, 2018 at 02:24:57AM -0600, Jan Beulich wrote:
> Drop unnecessary casts and use bool in favor of bool_t.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper
> Reviewed-by: Wei Liu
Reviewed-by: Roger Pau Monné
___
Xen-devel mai
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 Beuli
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 + disable
>>> 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 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)
>> {
>> +unsign
>>> 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 )
>> cluster_cpus_
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 1
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 { \
>>> +
>>> 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 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 OPT_XP
>>> 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 to
>>> 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 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;
#defi
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 04c77c18ada
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 l
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
https://lists.x
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 t
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
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é
> >
> 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()
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 enabl
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 a
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
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 enabl
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 reproduce
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
_
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.
> >
> > Please
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 between
>>> 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
> >
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 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. Befor
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
> > > inpu
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 time
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 dump_co
1 - 100 of 138 matches
Mail list logo
