On Mon, Jul 16, 2018 at 04:12:49PM -0700, Andrew Morton wrote:
> On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > There are several blockable mmu notifiers which might sleep in
> > mmu_notifier_invalidate_range_start and that is a problem for the
> >
flight 125179 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125179/
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
flight 125178 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125178/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125152
test-armhf-armhf-libvirt 14
flight 125255 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125255/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 60ee3bd8dbe70189cab18af733c42187c9b317c7
baseline version:
ovmf
On 07/16/2018 09:33 AM, Andrew Cooper wrote:
> On 06/06/18 14:37, Jan Beulich wrote:
>> >>> On 04.06.18 at 15:59, wrote:
>>> * State adjustments (and debug tracing) for #DB/#BP/#PF should not be done
>>>for `int $n` instructions. Updates to %cr2 occur even if the exception
>>>combines
flight 125175 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125175/
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 Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
flight 125171 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 124328
On 06/13/2018 05:18 AM, Ian Jackson wrote:
Jim: please read down to where I discuss
test-amd64-amd64-libvirt-pair. If you have any insight I'd appreciate
it. Let me know if you want me to preserve the logs, which will
otherwise expire in a few weeks.
Whoa, sorry for the delay. This mail
On Mon, 16 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 13/07/18 23:41, Stefano Stabellini wrote:
> > On Mon, 9 Jul 2018, Julien Grall wrote:
> > > On 07/07/18 00:12, Stefano Stabellini wrote:
> > > > Extend the existing device tree based multiboot protocol to include
> > > > information
On Mon, 16 Jul 2018, Jan Beulich wrote:
> >>> On 07.07.18 at 01:12, wrote:
> > @@ -389,29 +392,49 @@ static void dump_console_ring_key(unsigned char key)
> > free_xenheap_pages(buf, order);
> > }
> >
> > -/* CTRL- switches input direction between Xen and DOM0. */
> > +/*
> > + * CTRL-
On Mon, 16 Jul 2018, Jan Beulich wrote:
> >>> On 07.07.18 at 01:12, wrote:
> > --- a/xen/include/asm-x86/setup.h
> > +++ b/xen/include/asm-x86/setup.h
> > @@ -73,4 +73,6 @@ extern bool opt_dom0_shadow;
> > #endif
> > extern bool dom0_pvh;
> >
> > +#define max_init_domid (1)
>
> Why is this 1
On Mon, Jul 16, 2018 at 8:22 AM, Jan Beulich wrote:
On 16.07.18 at 13:59, wrote:
>> --- a/xen/arch/x86/tboot.c
>> +++ b/xen/arch/x86/tboot.c
>> @@ -391,7 +391,12 @@ void tboot_shutdown(uint32_t shutdown_type)
>> tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, _mac);
>> }
flight 74976 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74976/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 74948
This run is configured for baseline tests only.
flight 74975 xen-4.11-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74975/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10
flight 125247 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125247/
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
A couple of places in the code will need to clear/set flags in HCR_EL2
for a given vCPU and then replicate into the hardware. Introduce
helpers and replace open-coded version.
Signed-off-by: Julien Grall
---
I haven't find a good place for those new helpers so stick to
processor.h at the
At the moment, guest_walk_tables can either return 0, -EFAULT, -EINVAL.
The use of the last 2 are not clearly defined and used inconsistently in
the code. The current only caller does not care about the return
value and the value of it seems very limited (no way to differentiate
between the 15ish
Hi all,
This is patch series is a bunch of clean-up/improvement I collected while
working on the P2M and trap subsystems.
Cheers,
Julien Grall (15):
xen/arm: cpregs: Allow HSR_CPREG* to receive more than 1 parameter
xen/arm: cpregs: Fix typo in the documentation of TTBCR
xen/arm:
At the moment, HSR_CPREG is expected to receive only the co-processor
register name in parameter. Because the name is actually a define, this
may have been expanded by a previous macro.
Rather than imposing the use of _HSR_CPREG* in such cases, allow
HSR_CPREG to receive more than 1 parameter.
This is making the code slightly easier to understand.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 66d58fabd7..e826f57842 100644
--- a/xen/arch/arm/p2m.c
+++
!lpae_is_page(pte, level) && !lpae_is_superpage(pte, level) is
equivalent to !lpae_is_mapping(pte, level).
At the same time drop lpae_is_page(pte, level) that is now unused.
Signed-off-by: Julien Grall
---
xen/arch/arm/guest_walk.c | 2 +-
xen/include/asm-arm/lpae.h | 5 -
2 files
This will help to keep the naming consistent accross all lpae helpers.
No functional change intended.
Signed-off-by: Julien Grall
---
xen/arch/arm/guest_walk.c | 2 +-
xen/arch/arm/mm.c | 6 +++---
xen/arch/arm/p2m.c | 20 ++--
xen/include/asm-arm/lpae.h |
Currently, lpae_table can only work on entry from any level other than
3. Make it work with any level by extending the prototype to pass the
level.
At the same time, rename the function to lpae_is_mapping so naming stay
consistent accross all lpae_* helpers.
Signed-off-by: Julien Grall
---
GUEST_BUG_ON may be used in other files doing guest emulation.
Signed-off-by: Julien Grall
---
xen/arch/arm/traps.c| 24
xen/include/asm-arm/traps.h | 24
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git
Mem access has only an impact on the hardware translation between a
guest virtual address and the machine physical address. So it is not
necessary to fallback to memaccess for all the other case (e.g when it
is not possible to acquire the page behind the MFN).
Signed-off-by: Julien Grall
---
Currently, lpae_mapping can only work on entry from any level other than
3. Make it work with any level by extending the prototype to pass the
level.
At the same time, rename the function to lpae_is_mapping so naming stay
consistent accross lpae_* helpers.
Signed-off-by: Julien Grall
---
The p2m lock is only necessary to prevent gvirt_to_maddr failing when
break-before-make sequence is used in the P2M update concurrently on
another pCPU. So reduce the locking section.
Signed-off-by: Julien Grall
---
Note a newline has been dropped to keep the block together.
---
Comestic change to make clearer what is the return ('ret' is a bit
too generic).
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 07925a1be4..66d58fabd7 100644
---
Signed-off-by: Julien Grall
---
xen/include/asm-arm/cpregs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 4c74e8161b..07e5791983 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
Currently, lpae_is_{table, mapping} helpers will always return false on
entry with the valid bit unset. However, it would be useful to have them
operating on any entry. For instance to store information in advance but
still request a fault.
With that change, the p2m is now providing an overlay
The new helpers make easier to read the code by abstracting the way to
set/get an MFN from/to an LPAE entry. The helpers is using "walk" as the
bits are common for accross different LPAE stage.
At the same time, use the new helpers to replace the various open-coding
place.
Signed-off-by: Julien
flight 125241 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125241/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4c6d0de7bad46fc15fd34d394dffda3766e3a6a1
baseline version:
ovmf
On 16/07/18 17:45, Jan Beulich wrote:
> They're expensive, and nothing changes if MTRRs are disabled and any of
> the ranges gets changed, or if fixed range MTRRs are disabled and any of
> them gets changed.
>
> Signed-off-by: Jan Beulich
There is still far more room improve here, but this is a
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 commands to
> QEMU.
...
> + * This facility allows a command to be sent to
On 16/07/18 17:45, 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);
To be used in the way you want,
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 thing that comes to mind is some
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 used by two of the three case blocks and make them
initializers of the
They're expensive, and nothing changes if MTRRs are disabled and any of
the ranges gets changed, or if fixed range MTRRs are disabled and any of
them gets changed.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -472,7 +472,9 @@ bool_t
Signed-off-by: Jan Beulich
--- 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 &&
+ (opt_pcid == PCID_ALL ||
On Mon, Jul 16, 2018 at 04:28:00PM +0100, Anthony PERARD wrote:
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 760f2798c7..1e6fbb64a5 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1237,6 +1237,108 @@ int libxl__qmp_initializations(libxl__gc
flight 125237 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125237/
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 07.07.18 at 01:12, wrote:
> @@ -389,29 +392,49 @@ static void dump_console_ring_key(unsigned char key)
> free_xenheap_pages(buf, order);
> }
>
> -/* CTRL- switches input direction between Xen and DOM0. */
> +/*
> + * CTRL- switches input direction between Xen, Dom0 and
> + * DomUs.
>>> On 07.07.18 at 01:12, wrote:
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -73,4 +73,6 @@ extern bool opt_dom0_shadow;
> #endif
> extern bool dom0_pvh;
>
> +#define max_init_domid (1)
Why is this 1 rather than 0? Or is the name imprecise?
Jan
flight 125169 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125169/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 16
depriv-audit-qemu/create/privcmd blocked n/a
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 16 July 2018 15:56
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v12 07/11] x86/hvm: Introduce
>
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 16 July 2018 15:55
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v12 03/11] x86/hvm: Introduce
All the functions will be implemented in later patches.
This patch includes the API that libxl can use to send QMP commands to
QEMU.
This patch also include a description of the internal states of the QMP
client in charge of connecting to QEMU, sending command and handling
responces.
On Thu, Jul 12, 2018 at 05:36:00PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH v3.1] libxl: Design of an async API to
> issue QMP commands to QEMU"):
> > I don't think the state of a qmp connection can fit into
> > libxl__qmp_cmd_state. The "Active" state doesn't mean that a
flight 125167 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 123554
test-amd64-i386-xl
Wei Liu writes ("[PATCH v4 6/6] tools: --with-system-{ovmf,seabios,ipxe} should
provide absolute paths"):
> The paths shouldn't be set to "yes". We ask the user to set absolute
> paths because Xen's build system doesn't know where to search, and the
> build machine doesn't necessarily have those
Wei Liu writes ("[PATCH v4 5/6] tools: provide --with-system-ipxe"):
> This option lets user specify which binary is to be used as ipxe. If
> it is specified, the in-tree ipxe will not be built. This option is in
> line with other --with-system-* options we provide.
Acked-by: Ian Jackson
Wei Liu writes ("[PATCH v4 3/6] libxc: allow HVM guest to have modules"):
> Lift the loading code out of PVH specific branch. Take the chance to
> make the debug message more useful.
>
> Now the code needs to handle virt_base being UNSET_ADDR, which it is
> for HVM guest. In case virt_base is
Wei Liu writes ("[PATCH v4 1/6] Tools.mk.in: drop unused variables"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- hvm_save_cpu_ctxt() now returns err from
hvm_save_cpu_ctxt_one().
---
xen/arch/x86/hvm/hvm.c | 216 ++---
1 file changed, 113
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
---
Changes since V11:
- Changed the CONTINUE return to return 0.
---
xen/arch/x86/hvm/hvm.c | 18 +++
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V11:
- hvm_save_cpu_msrs() returns err from hvm_save_cpu_msrs_one().
---
xen/arch/x86/hvm/hvm.c | 105 +++--
1 file
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since v11:
- hvm_save_mtrr_msr() now returns err from hvm_save_mtrr_msr_one().
Note: This patch is based on Roger Pau Monne's series[1]
---
xen/arch/x86/hvm/mtrr.c | 81
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 | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 694eae6..f3430bb
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Removed the memset and added init with {}.
---
xen/arch/x86/cpu/mcheck/vmce.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git
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
---
Changes since V9:
- Change return of the save_one func to return hvm_save_entry.
---
xen/arch/x86/hvm/hvm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git
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 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 V11:
- Remove enum return type for save funcs.
---
xen/arch/x86/cpu/mcheck/vmce.c | 19
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- hvm_save_cpu_xsave_states_one() returns the err from
_hvm_init_entry().
- hvm_save_cpu_xsave_states() returns err from
hvm_save_cpu_xsave_states_one();
On 16/07/18 16:26, Jan Beulich wrote:
On 16.07.18 at 16:21, wrote:
>> So maybe changing the condition in cpupool_cpu_add() should be split out
>> into a patch of its own in order to be able to backport it?
>
> We'll want/need to backport this change anyway.
Okay, so even if its a bugfix on
flight 125235 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125235/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125151
build-amd64
>>> On 16.07.18 at 16:21, wrote:
> So maybe changing the condition in cpupool_cpu_add() should be split out
> into a patch of its own in order to be able to backport it?
We'll want/need to backport this change anyway.
Jan
___
Xen-devel mailing list
On 16/07/18 15:01, Jan Beulich wrote:
On 16.07.18 at 14:47, wrote:
>> On 16/07/18 14:19, Jan Beulich wrote:
>> On 16.07.18 at 13:47, wrote:
On 16/07/18 11:17, Jan Beulich wrote:
On 13.07.18 at 11:02, wrote:
>> On 11/07/18 14:04, Jan Beulich wrote:
>>> While I've
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 16 July 2018 15:14
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Wei Liu
Hi Stefano,
On 13/07/18 23:41, Stefano Stabellini wrote:
On Mon, 9 Jul 2018, Julien Grall wrote:
On 07/07/18 00:12, Stefano Stabellini wrote:
Extend the existing device tree based multiboot protocol to include
information regarding multiple domains to boot.
Signed-off-by: Stefano Stabellini
On Sat, Jul 07, 2018 at 12:05:19PM +0100, Paul Durrant wrote:
> This patch introduces the boilerplate for a new hypercall to allow a
> domain to control IOMMU mappings for its own pages.
> Whilst there is duplication of code between the native and compat entry
> points which appears ripe for some
On Sat, Jul 07, 2018 at 12:05:18PM +0100, Paul Durrant wrote:
> Turn iommu_map/unmap_page() into straightforward wrappers that check the
> existence of the relevant iommu_op and call through to it. This makes them
> usable by PV IOMMU code to be delivered in future patches.
> Leave the decision on
> -Original Message-
> From: Andrew Cooper
> Sent: 16 July 2018 15:08
> To: Paul Durrant ; 'Jan Beulich'
> ; xen-devel
> Subject: Re: [PATCH] x86/HVM: improve a few state load checks
>
> On 16/07/18 15:05, Paul Durrant wrote:
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++
On 16/07/18 15:05, Paul Durrant wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -976,14 +976,13 @@ unsigned long hvm_cr4_guest_valid_bits(c
>>
>> static int hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
>> {
>> -int vcpuid;
>> +unsigned int
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
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é
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
Changes since v1:
- New in this version.
---
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
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 July 2018 14:58
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
>
> Subject: [PATCH] x86/HVM: improve a few state load checks
>
> Using plain int for instance numbers looks quite dangerous without
> being
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
config/Tools.mk.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 2d6c440324..4cc9f29090 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -20,8 +20,6 @@ BCC := @BCC@
This option lets user specify which binary is to be used as ipxe. If
it is specified, the in-tree ipxe will not be built. This option is in
line with other --with-system-* options we provide.
Signed-off-by: Wei Liu
---
v3: ipxe should require rombios
Cc: Ian Jackson
---
config/Tools.mk.in
Lift the loading code out of PVH specific branch. Take the chance to
make the debug message more useful.
Now the code needs to handle virt_base being UNSET_ADDR, which it is
for HVM guest. In case virt_base is not set, it should be treated as
zero. In case PVH and PV, virt_base is set by the
And switch hvmloader/Makefile to use that binary. This will help later
when we change hvmloader to pick a user provided binary.
No functional change.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
v2: use intermediary file
Cc: Ian Jackson
---
tools/firmware/etherboot/Makefile | 7 ++-
Do not embed IPXE into Rombios anymore. Instead, it is loaded by the
toolstack from a file as a separate module.
Ability to let user specify an IPXE blob will come later.
No user visible change.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
v3: adjust libxl code a bit, addressed Jan's
Update commit messages. No code change in this version.
Wei Liu (6):
Tools.mk.in: drop unused variables
ipxe: produce a single binary from its build
libxc: allow HVM guest to have modules
tools: load IPXE from standalone file
tools: provide --with-system-ipxe
tools:
On 16/07/18 14:58, Jan Beulich wrote:
> Using plain int for instance numbers looks quite dangerous without
> being aware that hvm_load_instance() returns an unsigned quantity. Make
> this more explicit. Also replace uint16_t uses by unsigned int.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew
flight 125226 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125226/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 04c77c18ada08a796cfe1d7545c0e76429e1d3dc
baseline version:
freebsd
On 06/06/18 14:37, Jan Beulich wrote:
> >>> On 04.06.18 at 15:59, wrote:
>> * State adjustments (and debug tracing) for #DB/#BP/#PF should not be done
>>for `int $n` instructions. Updates to %cr2 occur even if the exception
>>combines to #DF.
>> * Don't opencode DR_STEP when updating
This run is configured for baseline tests only.
flight 74974 qemu-upstream-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 12
>>> On 16.07.18 at 15:15, wrote:
> On 16/07/18 13:29, Jan Beulich wrote:
> On 16.07.18 at 14:16, wrote:
>>> On 16/07/18 13:04, Jan Beulich wrote:
>>> On 13.07.18 at 22:03, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -31,6 +31,33 @@
> #include
On 16/07/18 13:29, Jan Beulich wrote:
On 16.07.18 at 14:16, wrote:
>> On 16/07/18 13:04, Jan Beulich wrote:
>> On 13.07.18 at 22:03, wrote:
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -31,6 +31,33 @@
#include
#include
+const struct
On 16/07/18 13:53, Jan Beulich wrote:
On 16.07.18 at 14:37, wrote:
>> On 13/07/18 09:13, Jan Beulich wrote:
>> On 12.07.18 at 17:45, wrote:
On 11/07/18 13:10, Jan Beulich wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@
>>> On 16.07.18 at 14:37, wrote:
> On 13/07/18 09:13, Jan Beulich wrote:
> On 12.07.18 at 17:45, wrote:
>>> On 11/07/18 13:10, Jan Beulich wrote:
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1040,6 +1040,13 @@ identical to the boot
>>> On 07.07.18 at 01:14, wrote:
> Add a clear statement about them, reflecting the current security
> support status of Kconfig options (no changes to current policies).
>
> Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
___
Xen-devel
On 16/07/18 14:19, Jan Beulich wrote:
On 16.07.18 at 13:47, wrote:
>> On 16/07/18 11:17, Jan Beulich wrote:
>> On 13.07.18 at 11:02, wrote:
On 11/07/18 14:04, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the
On 13/07/18 09:13, Jan Beulich wrote:
On 12.07.18 at 17:45, wrote:
>> On 11/07/18 13:10, Jan Beulich wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
>>> ### hpetbroadcast
>>> On 16.07.18 at 14:16, wrote:
> On 16/07/18 13:04, Jan Beulich wrote:
> On 13.07.18 at 22:03, wrote:
>>> --- a/xen/arch/x86/sysctl.c
>>> +++ b/xen/arch/x86/sysctl.c
>>> @@ -31,6 +31,33 @@
>>> #include
>>> #include
>>>
>>> +const struct cpu_policy system_policies[] = {
>> By the end
>>> On 16.07.18 at 13:59, wrote:
> --- a/xen/arch/x86/tboot.c
> +++ b/xen/arch/x86/tboot.c
> @@ -391,7 +391,12 @@ void tboot_shutdown(uint32_t shutdown_type)
> tboot_gen_xenheap_integrity(g_tboot_shared->s3_key, _mac);
> }
>
> -write_ptbase(idle_vcpu[0]);
> +/* During
>>> On 16.07.18 at 13:47, wrote:
> On 16/07/18 11:17, Jan Beulich wrote:
> On 13.07.18 at 11:02, wrote:
>>> On 11/07/18 14:04, 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
1 - 100 of 167 matches
Mail list logo
