(trying to send again, as I've replied yesterday but the email never
reached xen-devel).
On Mon, May 23, 2022 at 05:13:43PM +0200, Jan Beulich wrote:
> On 23.05.2022 16:37, Roger Pau Monné wrote:
> > On Wed, May 18, 2022 at 10:49:22AM +0200, Jan Beulich wrote:
> >> On 16.05.2022 16:31, Roger Pau M
It is possible to select a few different build configurations that results in
the unnecessary walking of the boot module list looking for a policy module.
This specifically occurs when the flask policy is enabled but either the dummy
or the SILO policy is selected as the enforcing policy. This is n
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH v3 2/2] xen/common: Use enhanced
> ASSERT_ALLOC_CONTEXT in xmalloc()
>
> Hi,
>
> On 07/05/2022 03:54, Henry Wang wrote:
> > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> > index e866e0d864..ea5
On 28/04/2022 13:55, Helge Deller wrote:
> [...]
> You may add:
> Acked-by: Helge Deller # parisc
>
> Helge
Hi Helge, do you think would be possible to still pick this one for
v5.19 or do you prefer to hold for the next release?
I'm working on V2, so if it's merged for 5.19 I won't send it agai
Hi Julien,
On 23.05.2022 22:00, Julien Grall wrote:
>
>
> On 23/05/2022 11:21, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>>
>> On 23.05.2022 12:05, Julien Grall wrote:
>>> Hi,
>>>
>>> On 23/05/2022 10:13, Michal Orzel wrote:
Introduce a command line parameter "maxcpus" on Arm to
On 24.05.2022 08:52, Lin Liu （刘林） wrote:
>>> On 23.05.2022 11:52, Lin Liu wrote:
> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p)
>return cpu_to_le3
On Mon, 23 May 2022, Oleksandr wrote:
> > > On Thu, 19 May 2022, Oleksandr wrote:
> > > > > On Wed, May 18, 2022 at 5:06 PM Oleksandr wrote:
> > > > > > On 18.05.22 17:32, Arnd Bergmann wrote:
> > > > > > > On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko
> > > > > > > wrote:
> > > > > > >
Hi Rafael,
On Wed, May 18, 2022 at 4:46 PM Rafael J. Wysocki wrote:
> On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> wrote:
> > m68k: Switch to new sys-off handler API
Sorry, I didn't realize this was going to interact with the new m68k
virtual machine support, which is included in the m6
On 24.05.2022 04:13, Lin Liu （刘林） wrote:
> On 23.05.2022 11:52, Lin Liu wrote:
>>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
>>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
>>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p)
>>>return cpu_to_le32(*p);
>>>
Hi Julien,
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: 2022年5月24日 3:50
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk ; Konrad Rzeszutek Wilk
> ; Ross Lagerwall
> Subje
On 23.05.2022 17:38, Andrew Cooper wrote:
> On 23/05/2022 15:56, Julien Grall wrote:
>> On 23/05/2022 15:50, Lin Liu wrote:
>>> Update to use byteswap to swap bytes
>>> be*_to_cpup(p) is short for be*to_cpu(*p), update to use latter
>>> one explictly
>>
>> But why?
>
> Because deleting code obfusc
On Mon, May 23, 2022 at 05:13:43PM +0200, Jan Beulich wrote:
> On 23.05.2022 16:37, Roger Pau Monné wrote:
> > On Wed, May 18, 2022 at 10:49:22AM +0200, Jan Beulich wrote:
> >> On 16.05.2022 16:31, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/include/asm/flushtlb.h
> >>> +++ b/xen/arch/x86/inclu
Hi Julien,
> On 22 May 2022, at 17:59, Julien Grall wrote:
>
> From: Julien Grall
>
> xsm_deasign_dtdevice() will indicate whether the caller is allowed
> to issue the operation. So the return value has to be checked.
>
> Spotted by clang static analyzer.
>
> Fixes: fe36483c ("xen/passth
Hi Julien,
> On 20 May 2022, at 13:09, Julien Grall wrote:
>
> From: Julien Grall
>
> In a follow-up patch, we will want to populate the boot allocator
> separately for arm64. The code will end up to be very similar to the one
> on arm32. So move out the code in a new helper populate_boot_allo
On Fri 2022-05-20 08:23:33, Guilherme G. Piccoli wrote:
> On 19/05/2022 20:45, Baoquan He wrote:
> > [...]
> >> I really appreciate the summary skill you have, to convert complex
> >> problems in very clear and concise ideas. Thanks for that, very useful!
> >> I agree with what was summarized above
On Mon 2022-05-23 11:56:12, Guilherme G. Piccoli wrote:
> On 19/05/2022 16:20, Scott Branden wrote:
> > [...]
> >> Hi Scott / Desmond, thanks for the detailed answer! Is this adapter
> >> designed to run in x86 only or you have other architectures' use cases?
> > The adapter may be used in any PCI
Hi Julien,
> On 23 May 2022, at 20:49, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, *_VIRT_END may either point to the address after the end
> or the last address of the region.
>
> The lack of consistency make quite difficult to reason with them.
>
> Furthermore, there is a
Hi Wei,
> On 24 May 2022, at 02:29, Wei Chen wrote:
>
> Hi Julien,
>
>> -Original Message-
>> From: Xen-devel On Behalf Of
>> Julien Grall
>> Sent: 2022年5月24日 3:50
>> To: xen-devel@lists.xenproject.org
>> Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini
>> ; Bertrand Marquis ;
>>
Hi Bertrand,
> -Original Message-
> From: Bertrand Marquis
> Sent: 2022年5月24日 16:07
> To: Wei Chen
> Cc: Julien Grall ; xen-devel@lists.xenproject.org; Julien
> Grall ; Stefano Stabellini ;
> Volodymyr Babchuk ; Konrad Rzeszutek Wilk
> ; Ross Lagerwall
> Subject: Re: [PATCH] xen/arm: Re
On 05/20/22 at 08:23am, Guilherme G. Piccoli wrote:
> On 19/05/2022 20:45, Baoquan He wrote:
> > [...]
> >> I really appreciate the summary skill you have, to convert complex
> >> problems in very clear and concise ideas. Thanks for that, very useful!
> >> I agree with what was summarized above.
>
flight 170712 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170712/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170687
test-amd64-amd64-xl-qemuu-ws16-amd64
On 24.05.2022 09:17, Lin Liu （刘林） wrote:
> On 23.05.2022 11:52, Lin Liu wrote:
>>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
>>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
>>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p)
>>>return
On 24/05/2022 03:11, Wei Chen wrote:
Hi Julien,
Hi Wei,
diff --git a/xen/arch/arm/include/asm/pmap.h
b/xen/arch/arm/include/asm/pmap.h
new file mode 100644
index ..74398b4c4fe6
--- /dev/null
+++ b/xen/arch/arm/include/asm/pmap.h
@@ -0,0 +1,32 @@
+#ifndef __ASM_PMAP_H__
+#defin
Hi Wei,
On 24/05/2022 09:16, Wei Chen wrote:
It seems you prefer to point _end to the address after the end. Even
though we got rid of the macro definition of _END. But we didn't agree
on how to use it. For me, when I first saw
"end = start + LIVEPATCH_VMAP_SIZE" I subconsciously think the -1 is
flight 170715 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170715/
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 05/24/22 at 10:01am, Petr Mladek wrote:
> On Fri 2022-05-20 08:23:33, Guilherme G. Piccoli wrote:
> > On 19/05/2022 20:45, Baoquan He wrote:
> > > [...]
> > >> I really appreciate the summary skill you have, to convert complex
> > >> problems in very clear and concise ideas. Thanks for that, ver
On Mon, May 23, 2022 at 06:24:48PM +0200, Roger Pau Monné wrote:
> On Mon, May 23, 2022 at 05:13:43PM +0200, Jan Beulich wrote:
> > On 23.05.2022 16:37, Roger Pau Monné wrote:
> > > On Wed, May 18, 2022 at 10:49:22AM +0200, Jan Beulich wrote:
> > >> On 16.05.2022 16:31, Roger Pau Monne wrote:
> > >
Booting with Shadow Stacks leads to the following assert on a debug
hypervisor:
Assertion 'local_irq_is_enabled()' failed at arch/x86/smp.c:265
[ Xen-4.17.0-10.24-d x86_64 debug=y Not tainted ]
CPU:0
RIP:e008:[] flush_area_mask+0x40/0x13e
[...]
Xen call trace:
[] R flush_area
flight 170714 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170714/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170711
test-amd64-amd64-qemuu-nested-amd 20
This commit creates a new doc to document the acquire resource interface. This
is a reference document.
Signed-off-by: Matias Ezequiel Vara Larsen
---
RFC: The current document still contains TODOs. I am not really sure why
different resources are implemented differently. I would like to understa
Subject could a little shorter I think:
x86/hvm: fix upcall vector usage with PIRQs on event channels
On Wed, May 18, 2022 at 02:27:14PM +0100, Jane Malalane wrote:
> Have is_hvm_pv_evtchn_domain() return true for vector callbacks for
> evtchn delivery set up on a per-vCPU basis via
> HVMOP_set_e
Instead of a virtual kernel address use a pointer of the associated
struct page as second parameter of gnttab_end_foreign_access().
Most users have that pointer available already and are creating the
virtual address from it, risking problems in case the memory is
located in highmem.
gnttab_end_fo
Am 18.05.2022 um 15:09 hat Stefan Hajnoczi geschrieben:
> Commit 1b7fd729559c ("block: rename buffer_alignment to
> guest_block_size") noted:
>
> At this point, the field is set by the device emulation, but completely
> ignored by the block layer.
>
> The last time the value of buffer_alignme
On 24.05.2022 14:41, Juergen Gross wrote:
> Instead of a virtual kernel address use a pointer of the associated
> struct page as second parameter of gnttab_end_foreign_access().
>
> Most users have that pointer available already and are creating the
> virtual address from it, risking problems in c
Hi Dmitry,
On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
wrote:
> Add kernel_can_power_off() helper that replaces open-coded checks of
> the global pm_power_off variable. This is a necessary step towards
> supporting chained power-off handlers.
>
> Signed-off-by: Dmitry Osipenko
Thanks for yo
On 5/24/22 16:14, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> wrote:
>> Add kernel_can_power_off() helper that replaces open-coded checks of
>> the global pm_power_off variable. This is a necessary step towards
>> supporting chained power-off handl
Hi Geert,
On Mon, May 23, 2022 at 8:08 PM Geert Uytterhoeven wrote:
>
> Hi Rafael,
>
> On Wed, May 18, 2022 at 4:46 PM Rafael J. Wysocki wrote:
> > On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> > wrote:
>
> > > m68k: Switch to new sys-off handler API
>
> Sorry, I didn't realize this was g
"Guilherme G. Piccoli" writes:
> The panic() function is somewhat convoluted - a lot of changes were
> made over the years, adding comments that might be misleading/outdated
> now, it has a code structure that is a bit complex to follow, with
> lots of conditionals, for example. The panic notifie
Hi Dmitry,
On Tue, May 24, 2022 at 3:41 PM Dmitry Osipenko
wrote:
> On 5/24/22 16:14, Geert Uytterhoeven wrote:
> > On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> > wrote:
> >> Add kernel_can_power_off() helper that replaces open-coded checks of
> >> the global pm_power_off variable. This is
On 18.05.2022 15:27, Jane Malalane wrote:
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -14,8 +14,14 @@
>
> #define has_32bit_shinfo(d)((d)->arch.has_32bit_shinfo)
>
> +/*
> + * Set to true if either the global vector-type callback or per-vCPU
> +
On 24.05.2022 12:50, Roger Pau Monne wrote:
> Booting with Shadow Stacks leads to the following assert on a debug
> hypervisor:
>
> Assertion 'local_irq_is_enabled()' failed at arch/x86/smp.c:265
> [ Xen-4.17.0-10.24-d x86_64 debug=y Not tainted ]
> CPU:0
> RIP:e008:[] flush_are
On 23.05.2022 17:40, Daniel P. Smith wrote:
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -55,19 +55,35 @@ static enum xsm_bootparam __initdata xsm_bootparam =
> XSM_BOOTPARAM_DUMMY;
> #endif
>
> +static bool __initdata init_policy =
> +#ifdef CONFIG_XSM_FLASK_DEFAULT
> +tr
+Saravana
On Mon, May 23, 2022 at 06:58:13PM -0700, Stefano Stabellini wrote:
> On Mon, 23 May 2022, Oleksandr wrote:
> > > > On Thu, 19 May 2022, Oleksandr wrote:
> > > > > > On Wed, May 18, 2022 at 5:06 PM Oleksandr
> > > > > > wrote:
> > > > > > > On 18.05.22 17:32, Arnd Bergmann wrote:
> > >
flight 170716 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 170714
test-amd64-amd64-do
On 24.05.22 04:58, Stefano Stabellini wrote:
Hello Stefano, all
On Mon, 23 May 2022, Oleksandr wrote:
On Thu, 19 May 2022, Oleksandr wrote:
On Wed, May 18, 2022 at 5:06 PM Oleksandr wrote:
On 18.05.22 17:32, Arnd Bergmann wrote:
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko
wrote:
On Tue, May 24, 2022 at 05:14:12PM +0200, Jan Beulich wrote:
> On 18.05.2022 15:27, Jane Malalane wrote:
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -14,8 +14,14 @@
> >
> > #define has_32bit_shinfo(d)((d)->arch.has_32bit_shinfo)
> >
> > +/
On Mon, May 23, 2022 at 11:40 AM Daniel P. Smith
wrote:
>
> It is possible to select a few different build configurations that results in
> the unnecessary walking of the boot module list looking for a policy module.
> This specifically occurs when the flask policy is enabled but either the dummy
libxl is leaking self pipes to child processes. These can be seen when
running with env var _LIBXL_DEBUG_EXEC_FDS=1:
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute:
/etc/xen/scripts/vif-bridge online
[Detaching after fork from child process 5099]
libxl: execing /et
unmap_grant_pages() currently waits for the pages to no longer be used.
In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
deadlock against i915: i915 was waiting for gntdev's MMU notifier to
finish, while gntdev was waiting for i915 to free its pages. I also
believe this is re
On Tue, May 24, 2022 at 05:27:35PM +0200, Jan Beulich wrote:
> On 24.05.2022 12:50, Roger Pau Monne wrote:
> > Booting with Shadow Stacks leads to the following assert on a debug
> > hypervisor:
> >
> > Assertion 'local_irq_is_enabled()' failed at arch/x86/smp.c:265
> > [ Xen-4.17.0-10.24-d x
On 5/24/22 11:50, Jan Beulich wrote:
> On 23.05.2022 17:40, Daniel P. Smith wrote:
>> --- a/xen/xsm/xsm_core.c
>> +++ b/xen/xsm/xsm_core.c
>> @@ -55,19 +55,35 @@ static enum xsm_bootparam __initdata xsm_bootparam =
>> XSM_BOOTPARAM_DUMMY;
>> #endif
>>
>> +static bool __initdata init_polic
On Tue, 24 May 2022, Oleksandr wrote:
> > On Mon, 23 May 2022, Oleksandr wrote:
> > > > > On Thu, 19 May 2022, Oleksandr wrote:
> > > > > > > On Wed, May 18, 2022 at 5:06 PM Oleksandr
> > > > > > > wrote:
> > > > > > > > On 18.05.22 17:32, Arnd Bergmann wrote:
> > > > > > > > > On Sat, May 7, 2022
On 5/24/22 12:17, Jason Andryuk wrote:
> On Mon, May 23, 2022 at 11:40 AM Daniel P. Smith
> wrote:
>>
>> It is possible to select a few different build configurations that results in
>> the unnecessary walking of the boot module list looking for a policy module.
>> This specifically occurs when th
On 5/21/22 6:47 AM, Thorsten Leemhuis wrote:
On 20.05.22 16:48, Chuck Zmudzinski wrote:
On 5/20/2022 10:06 AM, Jan Beulich wrote:
On 20.05.2022 15:33, Chuck Zmudzinski wrote:
On 5/20/2022 5:41 AM, Jan Beulich wrote:
On 20.05.2022 10:30, Chuck Zmudzinski wrote:
On 5/20/2022 2:59 AM, Chuck Zmu
On 5/24/22 18:03, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Tue, May 24, 2022 at 3:41 PM Dmitry Osipenko
> wrote:
>> On 5/24/22 16:14, Geert Uytterhoeven wrote:
>>> On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
>>> wrote:
Add kernel_can_power_off() helper that replaces open-coded chec
flight 170717 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 170714
test-amd64-amd64-do
On Sat, 14 May 2022, Julien Grall wrote:
> On 13/05/2022 22:07, Stefano Stabellini wrote:
> > diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
> > new file mode 100644
> > index 00..3e7ad54da7
> > --- /dev/null
> > +++ b/tools/helpers/init-dom0less.c
> > @@ -0,0 +1
From: Stefano Stabellini
snprintf returns the number of characters printed. A return value of
size or more means that the output was truncated.
Add a check for that in init-dom0less.
Signed-off-by: Stefano Stabellini
---
tools/helpers/init-dom0less.c | 38 ---
On Tue, 24 May 2022, Wei Chen wrote:
> Hi Julien,
>
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > Julien Grall
> > Sent: 2022年5月24日 3:47
> > To: xen-devel@lists.xenproject.org
> > Cc: Michal Orzel ; Julien Grall ;
> > Stefano Stabellini ; Julien Grall ;
> > Bertrand Marquis
Hi all,
This patch series is a follow-up from the MISRA C meeting last Thursday,
when we went through the list of MISRA C rules on the spreadsheet and
agreed to accept into the Xen coding style the first ones, starting from
Dir 2.1 up until Rule 5.1 (except for Rule 2.2) in descending popularity
o
From: Stefano Stabellini
Introduce a list of MISRA C rules that apply to the Xen hypervisor. The
list is in RST format.
Add a mention of the new list to CODING_STYLE.
Signed-off-by: Bertrand Marquis
Signed-off-by: Stefano Stabellini
---
CODING_STYLE | 6
docs/misra/rules.rst |
From: Stefano Stabellini
Add Rule 5.1, with the additional note that the character limit for Xen
is 63 characters.
The max length identifiers found by ECLAIR are:
__mitigate_spectre_bhb_clear_insn_start
domain_pause_by_systemcontroller_nosync
Both of them are 40 characters long. A limit of 63
flight 170719 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170719/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
"
On Tue, May 24, 2022 at 9:01 AM Rob Herring wrote:
>
> +Saravana
>
> On Mon, May 23, 2022 at 06:58:13PM -0700, Stefano Stabellini wrote:
> > On Mon, 23 May 2022, Oleksandr wrote:
> > > > > On Thu, 19 May 2022, Oleksandr wrote:
> > > > > > > On Wed, May 18, 2022 at 5:06 PM Oleksandr
> > > > >
flight 170718 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 170714
test-amd64-amd64-do
On 24.05.2022 18:46, Roger Pau Monné wrote:
> On Tue, May 24, 2022 at 05:27:35PM +0200, Jan Beulich wrote:
>> On 24.05.2022 12:50, Roger Pau Monne wrote:
>>> Booting with Shadow Stacks leads to the following assert on a debug
>>> hypervisor:
>>>
>>> Assertion 'local_irq_is_enabled()' failed at arch
Hi Stefano,
On 25.05.2022 01:35, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> snprintf returns the number of characters printed.
snprintf does not print anything but instead stores a composed string into a
buffer.
To be more correct, I would suggest to write:
"snprintf returns the n
On 24.05.2022 19:42, Daniel P. Smith wrote:
> On 5/24/22 11:50, Jan Beulich wrote:
>> On 23.05.2022 17:40, Daniel P. Smith wrote:
>>> @@ -36,10 +36,17 @@ int __init xsm_multiboot_policy_init(
>>> {
>>> int i;
>>> module_t *mod = (module_t *)__va(mbi->mods_addr);
>>> -int rc = 0;
>>>
68 matches
Mail list logo
