4664034cdc (tools/libs: move official headers to common directory)
forgot one .gitignore update.
Signed-off-by: Anthony PERARD
---
.gitignore | 1 -
1 file changed, 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 9513506dd9..cad5aacd8d 100644
--- a/.gitignore
+++ b/.gitignore
@@
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.toolstack-build-system-v1
Hi everyone,
I've been looking at reworking the build system we have for the "tools/", and
transforming it to something that suit it better. There are a lot
On 25.11.2021 14:39, Anthony PERARD wrote:
> This rework the livepatch/Makefile to make it less repetitive and make
> use of the facilities. All the targets to be built are now listed in
> $(extra-y) which will allow Rules.mk to build them without the need of
> a local target in a future patch.
>
On 25.11.2021 14:39, Anthony PERARD wrote:
Nit: In the title, do you mean "set ALL_OBJS in main Makefile; ..."?
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -285,8 +285,21 @@ CFLAGS += -flto
> LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
> endif
>
> +# Note that link order matters!
Julien Grall writes ("Re: [PATCH 1/7] xz: add fall-through comments to a switch
statement"):
> On 06/12/2021 16:12, Jan Beulich wrote:
> > Hmm, I did address both your and Ian's concerns in v2, admittedly by only
> > going as far as minimally necessary. I therefore wouldn't call this an
> > "open
On 25.11.2021 14:39, Anthony PERARD wrote:
> Currently, the xen/Makefile is re-parsed several times: once to start
> the build process, and several more time with Rules.mk including it.
> This makes it difficult to work with a Makefile used for several
> purpose, and it actually slow down the
On 06/12/2021 15:00, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 06.12.2021 15:39, Julien Grall wrote:
Hi Michal,
On 06/12/2021 14:19, Michal Orzel wrote:
vtimer_update_irqs, vtimer_update_irq and vcpu_update_evtchn_irq if
CONFIG_NEW_VGIC is not set.
enter_hypervisor_from_guest is
On 06/12/2021 16:24, Jan Beulich wrote:
On 06.12.2021 17:21, Julien Grall wrote:
On 06/12/2021 16:12, Jan Beulich wrote:
On 06.12.2021 17:06, Julien Grall wrote:
On 06/12/2021 15:06, Jan Beulich wrote:
On 06.12.2021 15:28, Julien Grall wrote:
I am not going to ack it but I am also not
On 06.12.2021 17:21, Julien Grall wrote:
> On 06/12/2021 16:12, Jan Beulich wrote:
>> On 06.12.2021 17:06, Julien Grall wrote:
>>> On 06/12/2021 15:06, Jan Beulich wrote:
On 06.12.2021 15:28, Julien Grall wrote:
> I am not going to ack it but I am also not going to Nack it if another
Hi Jan,
On 06/12/2021 16:12, Jan Beulich wrote:
On 06.12.2021 17:06, Julien Grall wrote:
On 06/12/2021 15:06, Jan Beulich wrote:
On 06.12.2021 15:28, Julien Grall wrote:
I am not going to ack it but I am also not going to Nack it if another
maintainer agrees with your approach.
FTAOD I'll
On 29.11.2021 16:33, Roger Pau Monne wrote:
> Pull out the code from xc_cpuid_apply_policy that applies a featureset
> to a cpu policy and place it on it's own standalone function that's
> part of the public interface.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Hi Jan
May I please ask, are you OK with the proposed changes?
On 03.12.21 22:33, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table frame GFN
in struct page_info directly instead of keeping it in
standalone status/shared arrays. This
On 06.12.2021 17:06, Julien Grall wrote:
> On 06/12/2021 15:06, Jan Beulich wrote:
>> On 06.12.2021 15:28, Julien Grall wrote:
>>> I am not going to ack it but I am also not going to Nack it if another
>>> maintainer agrees with your approach.
>>
>> FTAOD I'll be giving it a week or so, but unless
On 29.11.2021 16:33, Roger Pau Monne wrote:
> @@ -458,22 +456,6 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
> domid, bool restore,
> (p = calloc(1, sizeof(*p))) == NULL )
> goto out;
>
> -/* Get the host policy. */
> -rc = xc_get_cpu_featureset(xch,
Hi,
On 06/12/2021 15:06, Jan Beulich wrote:
On 06.12.2021 15:28, Julien Grall wrote:
On 06/12/2021 13:44, Jan Beulich wrote:
On 26.11.2021 13:52, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a switch
statement"):
On 26.11.2021 11:04, Julien Grall
Ian Jackson writes ("Xen 4.16 is released"):
> Xen 4.16, the product of 9 months' work by the Xen Project community,
> is now released.
I have now done the administrivia to staging-4.16 and it is open for
backports according to the usual protocol.
Ian.
On 06/12/2021 15:37, Luca Fancellu wrote:
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 95da0b7ab9cd..785a8fe81450 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -6,7 +6,7 @@
> #define MIN_FDT_ALIGN 8
> #define MAX_FDT_SIZE
Currently the maximum number of memory banks is fixed to
128, but on some new platforms that have a large amount
of memory, this value is not enough and prevents Xen
from booting.
Create a Kconfig parameter to set the value, by default
128.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/Kconfig
Currently the Xen UEFI stub can accept Xen boot arguments from
the Xen configuration file using the "options=" keyword, but also
directly from the device tree specifying xen,xen-bootargs
property.
When the configuration file is used, device tree boot arguments
are ignored and overwritten even if
Hi,
On 06/12/2021 14:20, Michal Orzel wrote:
to hypervisor when switching to AArch32 state.
According to section D1.20.2 of Arm Arm(DDI 0487A.j):
"If the general-purpose register was accessible from AArch32 state the
upper 32 bits either become zero, or hold the value that the same
On 29.11.2021 16:33, Roger Pau Monne wrote:
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -878,6 +878,26 @@ int xc_cpu_policy_get_cpuid(xc_interface *xch, const
> xc_cpu_policy_t *policy,
> return 0;
> }
>
> +int xc_cpu_policy_get_msr(xc_interface
On 29.11.2021 16:33, Roger Pau Monne wrote:
> Introduce an interface that returns a specific leaf/subleaf from a cpu
> policy in xen_cpuid_leaf_t format.
>
> This is useful to callers can peek data from the opaque
> xc_cpu_policy_t type.
>
> No caller of the interface introduced on this patch.
>
On 06.12.2021 16:11, Andrew Cooper wrote:
> On 06/12/2021 13:58, Jan Beulich wrote:
>> On 06.12.2021 14:08, Andrew Cooper wrote:
>>> While we've been diligent to ensure that the main text/data/rodata mappings
>>> have suitable restrictions, their aliases via the directmap were left fully
>>> RW.
From: "Longpeng(Mike)"
A CPU will not show up in virtualized environment which includes an
Enclave. The VM splits its resources into a primary VM and a Enclave
VM. While the Enclave is active, the hypervisor will ignore all requests
to bring up a CPU and this CPU will remain in CPU_UP_PREPARE
This is a repost of the previous patch (#2) and adding Boris
(Ostrovsky)'s suggestion regarding the XEN bits.
The previous post can be found at
https://lore.kernel.org/all/20211122154714.xaoxok3fpk5bg...@linutronix.de/
Sebastian
From: Boris Ostrovsky
If memory allocation in cpu_initialize_context() fails then it will
bring up the VCPU and leave with the corresponding CPU bit set in
xen_cpu_initialized_map.
The following (presumably successful) CPU bring up will BUG in
xen_pv_cpu_up() because nothing for that VCPU would
On 06.12.2021 16:10, Andrew Cooper wrote:
> On 06/12/2021 14:07, Jan Beulich wrote:
>> On 06.12.2021 14:55, Andrew Cooper wrote:
>>> On 06/12/2021 13:38, Andrew Cooper wrote:
popf is a horribly expensive instruction, while sti is an optimised
fastpath.
Switching popf for a
On 06/12/2021 13:58, Jan Beulich wrote:
> On 06.12.2021 14:08, Andrew Cooper wrote:
>> While we've been diligent to ensure that the main text/data/rodata mappings
>> have suitable restrictions, their aliases via the directmap were left fully
>> RW. Worse, we even had pieces of code making use of
On 06/12/2021 14:07, Jan Beulich wrote:
> On 06.12.2021 14:55, Andrew Cooper wrote:
>> On 06/12/2021 13:38, Andrew Cooper wrote:
>>> popf is a horribly expensive instruction, while sti is an optimised
>>> fastpath.
>>> Switching popf for a conditional branch and sti caused an 8% perf
>>>
On 06.12.2021 15:28, Julien Grall wrote:
> On 06/12/2021 13:44, Jan Beulich wrote:
>> On 26.11.2021 13:52, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a
>>> switch statement"):
On 26.11.2021 11:04, Julien Grall wrote:
> For this case, you
Hi Julien,
On 06.12.2021 15:39, Julien Grall wrote:
> Hi Michal,
>
> On 06/12/2021 14:19, Michal Orzel wrote:
>> vtimer_update_irqs, vtimer_update_irq and vcpu_update_evtchn_irq if
>> CONFIG_NEW_VGIC is not set.
>>
>> enter_hypervisor_from_guest is protecting calls to these functions
>> with
On 06.12.2021 15:39, Ian Jackson wrote:
> I am leaving Citrix to go and work for the Tor Project. My last day
> working full-time on Xen will be the 15th of December. While I won't
> be disappearing entirely, I won't have time to do patch review, and
> no-one should be waiting for my ack.
>
>
As below. CCing many people out of staging's MAINTAINERS entries for
bits of tools/.
I will be applying this shortly, to all stable trees, because I need
to do something about the just-released 4.16 tree and it will be
easier if I just make that like the others.
Note that my @citrix and
On 06.12.2021 15:20, Michal Orzel wrote:
> to hypervisor when switching to AArch32 state.
Do you perhaps mean "from AArch32 state" (also in further places below?
The 64-bit hypervisor runs in AArch64 state in all cases aiui.
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
>
Hi Michal,
On 06/12/2021 14:19, Michal Orzel wrote:
vtimer_update_irqs, vtimer_update_irq and vcpu_update_evtchn_irq if
CONFIG_NEW_VGIC is not set.
enter_hypervisor_from_guest is protecting calls to these functions
with CONFIG_NEW_VGIC but their definitions and declarations are not >
I am leaving Citrix to go and work for the Tor Project. My last day
working full-time on Xen will be the 15th of December. While I won't
be disappearing entirely, I won't have time to do patch review, and
no-one should be waiting for my ack.
Thanks to everyone for your support over the years.
On 29.11.2021 16:33, Roger Pau Monne wrote:
> --- a/tools/tests/cpu-policy/test-cpu-policy.c
> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
> @@ -386,16 +386,6 @@ static void test_msr_deserialise_failure(void)
> .msr = { .idx = 0xce, .flags = 1 },
> .rc = -EINVAL,
>
On 29.11.2021 16:33, Roger Pau Monne wrote:
> Introduce a helper based on the current Xen guest_cpuid code in order
> to fetch a cpuid leaf from a policy. The newly introduced function in
> cpuid.c should not be directly called and instead the provided
> x86_cpuid_get_leaf macro should be used
When using a PVH mode xenstore-stubdom the frame number of the console
should be a PFN instead of a MFN.
Signed-off-by: Juergen Gross
Reviewed-by: Andrew Cooper
---
V2:
- rename variable (Andrew Cooper)
---
tools/helpers/init-xenstore-domain.c | 8 +---
1 file changed, 5 insertions(+), 3
The console parameters for a PVH Xenstore-stubdom have been missing
or were just wrong.
Juergen Gross (2):
tools/helpers: fix PVH xenstore-stubdom console parameters
tools/helpers: set event channel for PVH xenstore-stubdom console
tools/helpers/init-xenstore-domain.c | 16 +---
In contrast to the PFN of the console ring page the event channel of
the console isn't being set automatically by xc_dom_build_image().
Call xc_hvm_param_set() explicitly for that reason.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
tools/helpers/init-xenstore-domain.c | 8
1
Hi Jan,
On 06/12/2021 13:44, Jan Beulich wrote:
On 26.11.2021 13:52, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a switch
statement"):
On 26.11.2021 11:04, Julien Grall wrote:
For this case, you provided some sort of an explanation but so far, I
With MB2 the boot loader may provide this information, allowing us to
obtain it without needing to enter real mode (assuming we don't need to
set a new mode from "vga=", but can instead inherit the one the
bootloader may have established).
Signed-off-by: Jan Beulich
---
v3: Re-base.
v2: New.
On 12/5/2021 6:31 PM, Juergen Gross wrote:
On 05.12.21 09:48, Tianyu Lan wrote:
On 12/5/2021 4:34 PM, Juergen Gross wrote:
On 05.12.21 09:18, Tianyu Lan wrote:
From: Tianyu Lan
hyperv Isolation VM requires bounce buffer support to copy
data from/to encrypted memory and so enable
There's no point going through %ax; the addition can be done directly in
%di.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/boot/mem.S
+++ b/xen/arch/x86/boot/mem.S
@@ -24,9 +24,7 @@ get_memory_map:
cmpw$E820_BIOS_MAX, bootsym(bios_e820nr) # up to this many entries
to hypervisor when switching to AArch32 state.
According to section D1.20.2 of Arm Arm(DDI 0487A.j):
"If the general-purpose register was accessible from AArch32 state the
upper 32 bits either become zero, or hold the value that the same
architectural register held before any AArch32 execution.
Replace (mainly) MOV forms with shorter insns (or sequences thereof).
Signed-off-by: Jan Beulich
---
Of course there's more room for improvement. For example there look to
be a number of LEAs which really could be MOVs.
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -121,8
Using Jcc to branch around a JMP is necessary only in pre-386 code,
where Jcc is limited to disp8. Use the opposite Jcc directly in two
places. Since it's adjacent, also convert an ORB to TESTB.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -332,8
vtimer_update_irqs, vtimer_update_irq and vcpu_update_evtchn_irq if
CONFIG_NEW_VGIC is not set.
enter_hypervisor_from_guest is protecting calls to these functions
with CONFIG_NEW_VGIC but their definitions and declarations are not
protected. This means that we are including them in the image even
There's no point in writing 80x25 text mode information via multiple
insns all storing immediate values. The data can simply be included
first thing in the vga_modes table, allowing the already present
REP MOVSB to take care of everything in one go.
While touching this also correct a related but
When booting directly from EFI, obtaining this information from EFI is
the only possible way. And even when booting with a boot loader
interposed, it's more clean not to use legacy BIOS calls for this
purpose. (The downside being that there are no "capabilities" that we
can retrieve the EFI way.)
On 06.12.21 14:24, Jan Beulich wrote:
On 06.12.2021 13:46, Juergen Gross wrote:
The console event channel might be 0 for the console, so use the value
of ~0 as invalid instead.
I may be missing something mini-os specific here, but in Xen channel 0
is always invalid. It's not just here that
On 12/6/2021 10:09 PM, Christoph Hellwig wrote:
Please spell swiotlb with a lower case s. Otherwise this look good
Acked-by: Christoph Hellwig
Feel free to carry this in whatever tree is suitable for the rest of the
patches.
Sure. Thanks for your ack and will update "swiotlb" in the next
GrUB2 can be told to leave the screen in the graphics mode it has been
using (or any other one), via "set gfxpayload=keep" (or suitable
variants thereof). In this case we can avoid doing another mode switch
ourselves. This in particular avoids possibly setting the screen to a
less desirable mode:
v3 has only some re-basing changes compared to v2. I have to admit that
I find it particularly sad that the enhancement done by patch 1 has not
made 4.16. This series had been submitted well in time.
1: make "vga=current" work with graphics modes
2: obtain video info from boot loader
3: EFI:
Hi Christoph:
Thanks for your review.
On 12/6/2021 10:06 PM, Christoph Hellwig wrote:
On Sun, Dec 05, 2021 at 03:18:10AM -0500, Tianyu Lan wrote:
+static bool hyperv_cc_platform_has(enum cc_attr attr)
+{
+#ifdef CONFIG_HYPERV
+ return attr == CC_ATTR_GUEST_MEM_ENCRYPT;
+#else
+
Please spell swiotlb with a lower case s. Otherwise this look good
Acked-by: Christoph Hellwig
Feel free to carry this in whatever tree is suitable for the rest of the
patches.
On 06.12.2021 14:55, Andrew Cooper wrote:
> On 06/12/2021 13:38, Andrew Cooper wrote:
>> popf is a horribly expensive instruction, while sti is an optimised fastpath.
>> Switching popf for a conditional branch and sti caused an 8% perf improvement
>> in various linux measurements.
>>
>>
On Sun, Dec 05, 2021 at 03:18:10AM -0500, Tianyu Lan wrote:
> +static bool hyperv_cc_platform_has(enum cc_attr attr)
> +{
> +#ifdef CONFIG_HYPERV
> + return attr == CC_ATTR_GUEST_MEM_ENCRYPT;
> +#else
> + return false;
> +#endif
> +}
Can we even end up here without CONFIG_HYPERV?
On 06.12.2021 14:08, Andrew Cooper wrote:
> While we've been diligent to ensure that the main text/data/rodata mappings
> have suitable restrictions, their aliases via the directmap were left fully
> RW. Worse, we even had pieces of code making use of this as a feature.
>
> Restrict the
On 06/12/2021 13:38, Andrew Cooper wrote:
> popf is a horribly expensive instruction, while sti is an optimised fastpath.
> Switching popf for a conditional branch and sti caused an 8% perf improvement
> in various linux measurements.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
>
flight 167179 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167179/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167168
test-armhf-armhf-libvirt 16
On 06.12.2021 14:07, Andrew Cooper wrote:
> It turns out that we've always been abusing the fact that .rodata is
> read/write during early boot, so we can sort the two tables.
>
> Now that we have a real __ro_after_init concept, reposition them to better
> match reality.
>
> Signed-off-by:
On 26.11.2021 13:52, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a
> switch statement"):
>> On 26.11.2021 11:04, Julien Grall wrote:
>>> For this case, you provided some sort of an explanation but so far, I am
>>> still waiting for a link to confirm
On 12/6/21 6:25 AM, Sebastian Andrzej Siewior wrote:
On 2021-11-24 21:17:34 [-0500], Boris Ostrovsky wrote:
On 11/24/21 5:54 PM, Thomas Gleixner wrote:
Any comment from XEN folks?
If memory allocation in cpu_initialize_context() fails we will not be
able to bring up the VCPU because
popf is a horribly expensive instruction, while sti is an optimised fastpath.
Switching popf for a conditional branch and sti caused an 8% perf improvement
in various linux measurements.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
From: Lasse Collin
With valid files, the safety margin described in lib/decompress_unxz.c
ensures that these buffers cannot overlap. But if the uncompressed size
of the input is larger than the caller thought, which is possible when
the input file is invalid/corrupt, the buffers can overlap.
From: Lasse Collin
This might matter, for example, if the underlying type of enum xz_check
was a signed char. In such a case the validation wouldn't have caught an
unsupported header. I don't know if this problem can occur in the kernel
on any arch but it's still good to fix it because some
From: Lasse Collin
It's a more logical place even if the resetting needs to be done
only once per LZMA2 stream (if lzma_reset() called in the middle
of an LZMA2 stream, .len will already be 0).
Link: https://lore.kernel.org/r/20211010213145.17462-4-xi...@kernel.org
Signed-off-by: Lasse Collin
Hi,
On 06.12.21 09:31, Jonas Blixt wrote:
Hello XEN developers,
We're working on a virtualized CAN driver for XEN (PV-CAN) with the intention
to upstream the patches.
In our project we use the PV CAN driver to expose a pysical CAN interface to
domU. We use cangw in
dom0 for routing between
On 06.12.2021 14:29, Jan Beulich wrote:
> While going through their 5.15.3 log I did notice two changes, which made
> me go check what else we might be missing. The series here is the result.
> Linux has also updated zstd, but that includes a pretty large change which
> I'm not ready to deal with
From: Lasse Collin
uncompressible -> incompressible
non-splitted -> non-split
Link: https://lore.kernel.org/r/20211010213145.17462-6-xi...@kernel.org
Signed-off-by: Lasse Collin
Signed-off-by: Gao Xiang
[Linux commit: 0a434e0a2c9f4395e4560aac22677ef25ab4afd9]
Signed-off-by: Jan Beulich
On 12/4/21 1:57 AM, Christophe JAILLET wrote:
So, maybe adding an "official" 'bitmap_size()' (which is already existing and
duplicated in a few places) would ease things.
It would replace the 'nr_minors = BITS_TO_LONGS(end) * BITS_PER_LONG;' and hide
the implementation details of the
From: Zhen Lei
Fix some spelling mistakes in comments:
sentinal ==> sentinel
compresed ==> compressed
immediatelly ==> immediately
dervied ==> derived
splitted ==> split
nore ==> not
independed ==> independent
asumed ==> assumed
Link:
From: Lasse Collin
s->dict.allocated was initialized to 0 but never set after a successful
allocation, thus the code always thought that the dictionary buffer has
to be reallocated.
Link: http://lkml.kernel.org/r/20191104185107.3b633...@tukaani.org
Reported-by: Yu Sun
Signed-off-by: Lasse
From: Lasse Collin
It's good style. I was also told that GCC 7 is more strict and might
give a warning when such comments are missing.
Suggested-by: Andrei Borzenkov
Signed-off-by: Lasse Collin
Signed-off-by: Jiri Kosina
[Linux commit: 5a244f48ecbbd03a11eb84819c5c599db81823ee]
Signed-off-by:
On 06.12.21 14:24, Jan Beulich wrote:
On 06.12.2021 13:46, Juergen Gross wrote:
The console event channel might be 0 for the console, so use the value
of ~0 as invalid instead.
I may be missing something mini-os specific here, but in Xen channel 0
is always invalid. It's not just here that
While going through their 5.15.3 log I did notice two changes, which made
me go check what else we might be missing. The series here is the result.
Linux has also updated zstd, but that includes a pretty large change which
I'm not ready to deal with right now. Them moving closer to the upstream
Top level table and intermediate table entries get explicitly set to
INVALID_MFN when un-allocated. There's therefore no need to use the more
expensive mfn_valid() when checking for that sentinel.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
---
The function returning a boolean indicator, make it return bool. Also
constify its struct domain parameter, albeit requiring to also adjust
mm_locked_by_me(). Furthermore the function is used by shadow code only.
Since mm_locked_by_me() needs touching anyway, also switch its return
type to bool.
On 06.12.2021 13:46, Juergen Gross wrote:
> The console event channel might be 0 for the console, so use the value
> of ~0 as invalid instead.
I may be missing something mini-os specific here, but in Xen channel 0
is always invalid. It's not just here that this value would be used as
a sentinel.
1: tidy paging_mfn_is_dirty()
2: replace most mfn_valid() in log-dirty handling
Jan
While we've been diligent to ensure that the main text/data/rodata mappings
have suitable restrictions, their aliases via the directmap were left fully
RW. Worse, we even had pieces of code making use of this as a feature.
Restrict the permissions, as we have no legitimate need for writeability
It turns out that we've always been abusing the fact that .rodata is
read/write during early boot, so we can sort the two tables.
Now that we have a real __ro_after_init concept, reposition them to better
match reality.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC:
On 06/12/2021 12:48, Juergen Gross wrote:
> When using a PVH mode xenstore-stubdom the frame number of the console
> should be a PFN instead of a MFN.
>
> Signed-off-by: Juergen Gross
I tried fixing this before, but it appears that it didn't stick (for
reasons pertaining to legacy pv-grub, so
When using a PVH mode xenstore-stubdom the frame number of the console
should be a PFN instead of a MFN.
Signed-off-by: Juergen Gross
---
tools/helpers/init-xenstore-domain.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/helpers/init-xenstore-domain.c
The console event channel might be 0 for the console, so use the value
of ~0 as invalid instead.
Signed-off-by: Juergen Gross
---
console/xencons_ring.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/console/xencons_ring.c b/console/xencons_ring.c
index
On 06.12.2021 12:38, Andrew Cooper wrote:
> On 06/12/2021 09:42, Jan Beulich wrote:
>> On 03.12.2021 16:30, Andrew Cooper wrote:
>>> On 03/12/2021 13:32, Jan Beulich wrote:
On 26.11.2021 13:34, Andrew Cooper wrote:
> Each IDT vector needs to land on an endbr64 instruction. This is
>
On 06/12/2021 09:42, Jan Beulich wrote:
> On 03.12.2021 16:30, Andrew Cooper wrote:
>> On 03/12/2021 13:32, Jan Beulich wrote:
>>> On 26.11.2021 13:34, Andrew Cooper wrote:
Each IDT vector needs to land on an endbr64 instruction. This is
especially
important for the #CP handler,
On 2021-11-24 21:17:34 [-0500], Boris Ostrovsky wrote:
>
> On 11/24/21 5:54 PM, Thomas Gleixner wrote:
> > Any comment from XEN folks?
>
>
> If memory allocation in cpu_initialize_context() fails we will not be
> able to bring up the VCPU because xen_cpu_initialized_map bit at the
> top of that
On 26.11.2021 13:34, Andrew Cooper wrote:
> With all the pieces now in place, turn CET-IBT on when available.
>
> MSR_S_CET, like SMEP/SMAP, controls Ring1 meaning that ENDBR_EN can't be
> enabled for Xen independently of PV32 kernels. As we already disable PV32 for
> CET-SS, extend this to all
flight 167174 xen-unstable real [real]
flight 167208 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167174/
http://logs.test-lab.xenproject.org/osstest/logs/167208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 26.11.2021 17:38, Andrew Cooper wrote:
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -11,6 +11,8 @@
> #include
> #include
>
> +bool __initdata efi_no_cet_ibt;
I'm having trouble seeing what this is needed for - when this file gets
built, neither boot.c nor
On 26.11.2021 13:34, Andrew Cooper wrote:
> --- a/xen/arch/x86/acpi/wakeup_prot.S
> +++ b/xen/arch/x86/acpi/wakeup_prot.S
> @@ -63,7 +63,24 @@ ENTRY(s3_resume)
> pushq %rax
> lretq
> 1:
> -#ifdef CONFIG_XEN_SHSTK
> +#if defined(CONFIG_XEN_SHSTK) || defined(CONFIG_XEN_IBT)
> +
On 03.12.2021 16:30, Andrew Cooper wrote:
> On 03/12/2021 13:32, Jan Beulich wrote:
>> On 26.11.2021 13:34, Andrew Cooper wrote:
>>> Each IDT vector needs to land on an endbr64 instruction. This is especially
>>> important for the #CP handler, which will escalate to #DF if the endbr64 is
>>>
flight 167178 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167178/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
> On 6 Dec 2021, at 07:27, Jan Beulich wrote:
>
> On 03.12.2021 17:10, Luca Fancellu wrote:
>>> On 3 Dec 2021, at 10:56, Jan Beulich wrote:
>>>
>>> When it was introduced, it was imo placed way too high up, making it
>>> necessary to forward-declare way too many static functions. Move it
On 26.11.2021 13:33, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
Elsewhere in this file we have
rc = map ? map_mmio_regions(d, _gfn(pfn), nr_pages, _mfn(pfn))
: unmap_mmio_regions(d, _gfn(pfn), nr_pages, _mfn(pfn));
Hello XEN developers,
We're working on a virtualized CAN driver for XEN (PV-CAN) with the intention
to upstream the patches.
In our project we use the PV CAN driver to expose a pysical CAN interface to
domU. We use cangw in
dom0 for routing between the physical interface and the PV CAN
On 03.12.2021 15:10, Andrew Cooper wrote:
> On 03/12/2021 13:59, Jan Beulich wrote:
>> On 26.11.2021 17:33, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -190,6 +190,10 @@ $(TARGET)-syms: prelink.o xen.lds
>>> $(MAKE) -f $(BASEDIR)/Rules.mk efi-y=
201 - 300 of 300 matches
Mail list logo
