Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
as noted in docs/igd-assign.txt in the Qemu source code.
Currently, when the xl toolstack is used to configure a Xen HVM guest with
Intel IGD passthrough to the guest with the Qemu upstream device model,
a Qemu emulated PCI devi
On 1/10/23 3:16 AM, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
>> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
>> as noted in docs/igd-assign.txt in the Qemu source code.
>>
>> Currently, when the xl toolstack is used to c
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 08/14] xen/arm32: head: Introduce an helper to flush the
> TLBs
>
> From: Julien Grall
>
> The sequence for flushing the TLBs is 4 instruction long and often
> requires an explanation how it works.
>
> So create a helper and use it i
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 07/14] xen/arm32: head: Jump to the runtime mapping in
> enable_mmu()
>
> From: Julien Grall
>
> At the moment, enable_mmu() will return to an address in the 1:1 mapping
> and each path is responsible to switch to the runtime mapping.
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 06/14] xen/arm32: head: Replace "ldr rX, =" with
> "mov_w rX, "
>
> From: Julien Grall
>
> "ldr rX, =" is used to load a value from the literal pool. This
> implies a memory access.
>
> This can be avoided by using the macro mov_w wh
struct xen_build_id and struct xen_varbuf are identical from an ABI point of
view, so XENVER_build_id can reuse xenver_varbuf_op() rather than having it's
own almost identical copy of the logic.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefan
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
---
xen/common/kernel.c | 11 +--
xen/common/version.c | 4 ++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/xen/common/k
A split in virtual address space is only applicable for x86 PV guests.
Furthermore, the information returned for x86 64bit PV guests is wrong.
Explain the problem in version.h, stating the other information that PV guests
need to know.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan
See patch 3 for details of the problem. Other patches fix other errors found
while investigating.
Some patches committed straight from v1. Several new patches with additional
cleanup.
Andrew Cooper (5):
xen/version: Drop bogus return values for XENVER_platform_parameters
xen/version: Calcul
The arch_get_xen_caps() infrastructure is horribly inefficient, for something
that is constant after features have been resolved on boot.
Every instance used snprintf() to format constants into a string (which gets
shorter when %d gets resolved!), which gets double buffered on the stack.
Switch t
Recently in XenServer, we have encountered problems caused by both
XENVER_extraversion and XENVER_commandline having fixed bounds.
More than just the invariant size, the APIs/ABIs also broken by typedef-ing an
array, and using an unqualified 'char' which has implementation-specific
signed-ness
Pr
On Fri, Jan 13, 2023 at 08:40:15PM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
> >
> > Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> > Xen PV guest") missed one code path accessing real_mode_header, leading
> > to dereferencing
On 1/13/23 4:33 AM, Igor Mammedov wrote:
> On Thu, 12 Jan 2023 23:14:26 -0500
> Chuck Zmudzinski wrote:
>
>> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
>> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:
>> >> I think the change Michael suggests is very minimalistic: Move
On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
>
> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> Xen PV guest") missed one code path accessing real_mode_header, leading
> to dereferencing NULL when suspending the system under Xen:
>
> [ 348.284004] PM: suspen
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> Looking at the Neoverse N1 errata document, it is not clear to me
> why the TLBI repeat workaround is not applied for TLB flush by VA.
>
> The TBL flush by VA helpers are used in flush_xen_tlb_range_va_local()
> and
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> Switching TTBR while the MMU is on is not safe. Now that the identity
> mapping will not clash with the rest of the memory layout, we can avoid
> creating temporary page-tables every time a CPU is brought up.
>
> The
On Fri, Jan 13, 2023 at 02:16:44PM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > Since we can't do CALL/RET until GS is restored and CR[04] pinning is
> > of dubious value in this code path, simply write the stored values.
> >
> > Signed-off-by: Peter Zijlstra (Intel)
> > ---
> >
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
> still on.
>
> Switching TTBR is like replacing existing mappings with new ones. So
> we need to follow the break-before-make sequence.
>
> In thi
On Fri, Jan 13, 2023 at 03:20:37PM +0100, Juergen Gross wrote:
> On 13.01.23 14:44, Marek Marczykowski-Górecki wrote:
> > But, unrelated to this bug, it did get message like in
> > https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg107609.html
> > (WARNING: CPU: 1 PID: 0 at arch/x86/mm
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> In follow-up patches we will need to have part of Xen identity mapped in
> order to safely switch the TTBR.
>
> On some platform, the identity mapping may have to start at 0. If we always
> keep the identity region ma
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> Xen is currently not fully compliant with the Arm Arm because it will
> switch the TTBR with the MMU on.
>
> In order to be compliant, we need to disable the MMU before
> switching the TTBR. The implication is the pag
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, the temporary mapping is only used when the virtual
> runtime region of Xen is clashing with the physical region.
>
> In follow-up patches, we will rework how secondary CPU bring-up works
> and it will
flight 175749 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt-qcow2
> On 13 Jan 2023, at 10:11, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, bootloaders can load Xen anywhere in memory but the
> region 2MB - 4MB. While I am not aware of any issue, we have no way
> to tell the bootloader to avoid that region.
>
> In addition to that, in the f
On 1/13/23 16:22, Jan Beulich wrote:
On 13.01.2023 14:53, Xenia Ragiadakou wrote:
On 1/13/23 15:24, Jan Beulich wrote:
On 13.01.2023 14:07, Xenia Ragiadakou wrote:
On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
On 1/13/23 11:53, Jan Beulich wrote:
On 13.
flight 175752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl 5 hos
On 13.01.2023 14:53, Xenia Ragiadakou wrote:
> On 1/13/23 15:24, Jan Beulich wrote:
>> On 13.01.2023 14:07, Xenia Ragiadakou wrote:
>>> On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
> On 1/13/23 11:53, Jan Beulich wrote:
>> On 13.01.2023 10:34, Xenia
On 13.01.23 14:44, Marek Marczykowski-Górecki wrote:
But, unrelated to this bug, it did get message like in
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg107609.html
(WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:523 switch_mm_irqs_off+0x230/0x4a0)
Hmm, is applying the attached
Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:
[ 348.284004] PM: suspend entry (deep)
[ 348.289532] Filesystems sync: 0.005 seconds
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 05/14] xen/arm: Clean-up the memory layout
>
> From: Julien Grall
>
> In a follow-up patch, the base address for the common mappings will
> vary between arm32 and arm64. To avoid any duplication, define
> every mapping in the common r
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 04/14] xen/arm: flushtlb: Reduce scope of barrier for the
> TLB range flush
>
> From: Julien Grall
>
> At the moment, flush_xen_tlb_range_va{,_local}() are using system
> wide memory barrier. This is quite expensive and unnecessary.
>
On 1/13/23 15:24, Jan Beulich wrote:
On 13.01.2023 14:07, Xenia Ragiadakou wrote:
On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
On 1/13/23 10:47, Jan Beulich wrote:
--- a
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 03/14] xen/arm32: flushtlb: Reduce scope of barrier for
> local TLB flush
>
> From: Julien Grall
>
> Per G5-9224 in ARM DDI 0487I.a:
>
> "A DSB NSH is sufficient to ensure completion of TLB maintenance
> instructions that apply to a
On Fri, Jan 13, 2023 at 09:08:35AM +0100, Juergen Gross wrote:
> On 13.01.23 03:57, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > 6.1.3 as PV dom0 crashes when attempting to suspend. 6.1.1 works. The
> > crash:
> >
> > [ 348.284004] PM: suspend entry (deep)
> > [ 348.289532] Files
On 13.01.2023 14:07, Xenia Ragiadakou wrote:
>
> On 1/13/23 14:12, Jan Beulich wrote:
>> On 13.01.2023 12:55, Xenia Ragiadakou wrote:
>>> On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
> On 1/13/23 10:47, Jan Beulich wrote:
>> --- a/xen/drivers/passt
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 02/14] xen/arm64: flushtlb: Implement the TLBI repeat
> workaround for TLB flush by VA
>
> From: Julien Grall
>
> Looking at the Neoverse N1 errata document, it is not clear to me
> why the TLBI repeat workaround is not applied for TL
* Peter Zijlstra wrote:
> Since we can't do CALL/RET until GS is restored and CR[04] pinning is
> of dubious value in this code path, simply write the stored values.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/power/cpu.c |4 ++--
> 1 file changed, 2 insertions(+), 2 delet
On 1/13/23 14:12, Jan Beulich wrote:
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
On 1/13/23 10:47, Jan Beulich wrote:
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -56
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8ea3843ea8e8..27f38729302b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
>>
On Fri, Jan 13, 2023 at 10:17:46AM +0100, Peter Zijlstra wrote:
> > (2) Tracing with QEMU I still see two `sarq $5, %gs:0x1337B33F` before
> > `%gs` is restored. Those correspond to the calls from
> > `secondary_startup_64` in `arch/x86/kernel/head_64.S` to
> > `verify_cpu` and `sev_ve
Hello Julien,
>>>xentrace should work on upstream Xen. What did you version did you try?
While building my image using the BSP-linux of NXP, the version that was
downloaded is Xen 4.14.
>>>Can you also clarify the error you are seen?
The error I receive while tipping xentrace is: Command no
> On 13 Jan 2023, at 08:53, Julien Grall wrote:
>
> Hi Luca,
>
> On 12/01/2023 10:46, Luca Fancellu wrote:
>>> On 11 Jan 2023, at 17:16, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> As this is an RFC, I will be mostly making general comments.
>> Hi Julien,
>> Thank you.
>>>
>>> On 11/01/20
Hi All,
On 10/01/2023 12:30, Dmytro Firsov wrote:
On 09.01.23 11:36, Oleksandr Tyshchenko wrote:
On 08.01.23 18:06, Julien Grall wrote:
Hello Julien, Ayan, all
Hi Ayan,
...
The changes look good to me (with a few of comments below). That
said, before acking the code, I would like an existin
Currently, kernel_uimage_probe() does not read the load/entry point address
set in the uImge header. Thus, info->zimage.start is 0 (default value). This
causes, kernel_zimage_place() to treat the binary (contained within uImage)
as position independent executable. Thus, it loads it at an incorrect
On 13.01.2023 12:55, Xenia Ragiadakou wrote:
> On 1/13/23 11:53, Jan Beulich wrote:
>> On 13.01.2023 10:34, Xenia Ragiadakou wrote:
>>> On 1/13/23 10:47, Jan Beulich wrote:
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -56,6 +56,13 @@ void __i
Currently it's impossible to get CPU's microcode revision after late
loading without looking into Xen logs which is not always convenient.
Add an option to xen-ucode tool to print the currently loaded ucode
version and also print it during usage info.
Add a new platform op in order to get the requ
(CC Paul as well)
On 1/13/23 11:53, Jan Beulich wrote:
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
On 1/13/23 10:47, Jan Beulich wrote:
First of all the variable is meaningful only when an IOMMU is in use for
a guest. Qualify the check accordingly, like done elsewhere. Furthermore
the contro
On 13/01/2023 8:47 am, Jan Beulich wrote:
As far as the subject goes, I really wouldn't call this "sanitise". The
behaviour is crazy, and broken.
"Make shadow consistent with how HAP works" feels somewhat better.
> First of all the variable is meaningful only when an IOMMU is in use for
> a g
Hi Julien,
> -Original Message-
> Subject: [PATCH v4 01/14] xen/arm64: flushtlb: Reduce scope of barrier for
> local TLB flush
>
> From: Julien Grall
>
> Per D5-4929 in ARM DDI 0487H.a:
> "A DSB NSH is sufficient to ensure completion of TLB maintenance
> instructions that apply to a si
On 13.01.2023 12:06, osstest service owner wrote:
> flight 175751 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/175751/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64 6 x
flight 175751 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175751/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 173462
build-amd64-xsm
flight 175750 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 175743
build-amd64-xsm
Hi,
On 13/01/2023 10:45, Michal Orzel wrote:
On 13/01/2023 11:11, Julien Grall wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
From: Julien Grall
"ldr rX, =" is used to load a value from the lite
On 13/01/2023 11:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> The sequence for flushing the TLBs is 4 instruction long and often
> requires an explanation how it works.
>
> So create a helper and use it in the boot code (switch_ttbr() is left
> alone until we decide the semantic of
On 13/01/2023 11:11, Julien Grall wrote:
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> From: Julien Grall
>
> "ldr rX, =" is used to load a value from the literal pool. This
> implies a memory
> -Original Message-
> From: Julien Grall
> Sent: Friday, January 13, 2023 6:07 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk ; Julien Grall
>
> Subject: Re: [PATCH v2 01/40] xen/arm: remove xen_phys_st
From: Julien Grall
Xen is currently not fully compliant with the Arm Arm because it will
switch the TTBR with the MMU on.
In order to be compliant, we need to disable the MMU before
switching the TTBR. The implication is the page-tables should
contain an identity mapping of the code switching th
From: Julien Grall
At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
still on.
Switching TTBR is like replacing existing mappings with new ones. So
we need to follow the break-before-make sequence.
In this case, it means the MMU needs to be switched off while the
TTBR is upda
From: Julien Grall
In follow-up patches we will need to have part of Xen identity mapped in
order to safely switch the TTBR.
On some platform, the identity mapping may have to start at 0. If we always
keep the identity region mapped, NULL pointer dereference would lead to
access to valid mapping
From: Julien Grall
At the moment, the temporary mapping is only used when the virtual
runtime region of Xen is clashing with the physical region.
In follow-up patches, we will rework how secondary CPU bring-up works
and it will be convenient to use the fixmap area for accessing
the root page-tab
From: Julien Grall
Switching TTBR while the MMU is on is not safe. Now that the identity
mapping will not clash with the rest of the memory layout, we can avoid
creating temporary page-tables every time a CPU is brought up.
The arm32 code will use a different approach. So this issue is for now
o
(missed to CC Paul on the original submission)
On 13.01.2023 09:47, Jan Beulich wrote:
> First of all the variable is meaningful only when an IOMMU is in use for
> a guest. Qualify the check accordingly, like done elsewhere. Furthermore
> the controlling command line option is supposed to take eff
On 13/01/2023 8:48 am, Jan Beulich wrote:
> While c61a6f74f80e ("x86: enforce consistent cachability of MMIO
> mappings") correctly converted one !mfn_valid() check there, two others
> were wrongly left untouched: Both cachability control and log-dirty
> tracking ought to be uniformly handled/exclu
From: Julien Grall
At the moment, bootloaders can load Xen anywhere in memory but the
region 2MB - 4MB. While I am not aware of any issue, we have no way
to tell the bootloader to avoid that region.
In addition to that, in the future, Xen may grow over 2MB if we
enable feature like UBSAN or GCOV
From: Julien Grall
The sequence for flushing the TLBs is 4 instruction long and often
requires an explanation how it works.
So create a helper and use it in the boot code (switch_ttbr() is left
alone until we decide the semantic of the call).
Note that in secondary_switched, we were also flushi
From: Julien Grall
"ldr rX, =" is used to load a value from the literal pool. This
implies a memory access.
This can be avoided by using the macro mov_w which encode the value in
the immediate of two instructions.
So replace all "ldr rX, =" with "mov_w rX, ".
No functional changes intended.
S
From: Julien Grall
At the moment, enable_mmu() will return to an address in the 1:1 mapping
and each path is responsible to switch to the runtime mapping.
In a follow-up patch, the behavior to switch to the runtime mapping
will become more complex. So to avoid more code/comment duplication,
move
From: Julien Grall
In a follow-up patch, the base address for the common mappings will
vary between arm32 and arm64. To avoid any duplication, define
every mapping in the common region from the previous one.
Take the opportunity to:
* add missing *_SIZE for FIXMAP_VIRT_* and XEN_VIRT_*
*
From: Julien Grall
Looking at the Neoverse N1 errata document, it is not clear to me
why the TLBI repeat workaround is not applied for TLB flush by VA.
The TBL flush by VA helpers are used in flush_xen_tlb_range_va_local()
and flush_xen_tlb_range_va(). So if the range size if a fixed size smalle
From: Julien Grall
At the moment, flush_xen_tlb_range_va{,_local}() are using system
wide memory barrier. This is quite expensive and unnecessary.
For the local version, a non-shareable barrier is sufficient.
For the SMP version, an inner-shareable barrier is sufficient.
Furthermore, the initia
From: Julien Grall
Per G5-9224 in ARM DDI 0487I.a:
"A DSB NSH is sufficient to ensure completion of TLB maintenance
instructions that apply to a single PE. A DSB ISH is sufficient to
ensure completion of TLB maintenance instructions that apply to PEs
in the same Inner Shareable domain.
"
Thi
From: Julien Grall
Per D5-4929 in ARM DDI 0487H.a:
"A DSB NSH is sufficient to ensure completion of TLB maintenance
instructions that apply to a single PE. A DSB ISH is sufficient to
ensure completion of TLB maintenance instructions that apply to PEs
in the same Inner Shareable domain.
"
This
From: Julien Grall
Hi all,
Currently, Xen on Arm will switch TTBR whilst the MMU is on. This is
similar to replacing existing mappings with new ones. So we need to
follow a break-before-make sequence.
When switching the TTBR, we need to temporarily disable the MMU
before updating the TTBR. This
On 13.01.2023 06:29, Penny Zheng wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -13,9 +13,10 @@ config ARM
> def_bool y
> select HAS_ALTERNATIVE if !ARM_V8R
> select HAS_DEVICE_TREE
> + select HAS_FIXMAP if !ARM_V8R
> select HAS_PASSTHROUGH
>
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
These two variables are stale variables, they only have declarations
in config.h, they don't have any definition and no any code is using
these two variables. So in this patch, we remove them from config.h.
Signed-off-by: Wei Ch
Hi Michal,
On 06/01/2023 10:41, Michal Orzel wrote:
On 05/01/2023 13:15, Andrew Cooper wrote:
On 05/01/2023 11:19 am, Julien Grall wrote:
On 05/01/2023 09:59, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
I have a clarification.
On 05/01/2023 09:26, Julien Grall wrote:
CAUTION: This messa
On 13.01.23 10:53, Julien Grall wrote:
Hi Juergen,
On 12/01/2023 05:49, Juergen Gross wrote:
On 11.01.23 18:48, Julien Grall wrote:
Hi Juergen,
On 11/01/2023 08:59, Juergen Gross wrote:
... to make sure domain_nbentry_add() is not returning a negative value.
Then it would not work.
A good
On 13.01.2023 10:34, Xenia Ragiadakou wrote:
>
> On 1/13/23 10:47, Jan Beulich wrote:
>> First of all the variable is meaningful only when an IOMMU is in use for
>> a guest. Qualify the check accordingly, like done elsewhere. Furthermore
>> the controlling command line option is supposed to take e
Hi Juergen,
On 12/01/2023 05:49, Juergen Gross wrote:
On 11.01.23 18:48, Julien Grall wrote:
Hi Juergen,
On 11/01/2023 08:59, Juergen Gross wrote:
... to make sure domain_nbentry_add() is not returning a negative
value. Then it would not work.
A good example imagine you have a transaction r
On 13.01.2023 06:29, Penny Zheng wrote:
> --- a/xen/include/xen/vmap.h
> +++ b/xen/include/xen/vmap.h
> @@ -89,15 +89,27 @@ static inline void vfree(void *va)
> ASSERT_UNREACHABLE();
> }
>
> +#ifdef CONFIG_HAS_MPU
> +void __iomem *ioremap(paddr_t, size_t);
> +#else
> void __iomem *ioremap(
On 13.01.2023 06:29, Penny Zheng wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -43,6 +43,9 @@ config HAS_EX_TABLE
> config HAS_FAST_MULTIPLY
> bool
>
> +config HAS_FIXMAP
> + bool
I think it'll end up misleading if this option is not selected by x86
as well. So imo
On 13.01.2023 06:29, Penny Zheng wrote:
> VMAP in MMU system, is used to remap a range of normal memory
> or device memory to another virtual address with new attributes
> for specific purpose, like ALTERNATIVE feature. Since there is
> no virtual address translation support in MPU system, we can
>
On 1/13/23 10:47, Jan Beulich wrote:
First of all the variable is meaningful only when an IOMMU is in use for
a guest. Qualify the check accordingly, like done elsewhere. Furthermore
the controlling command line option is supposed to take effect on VT-d
only. Since command line parsing happens
On Thu, 12 Jan 2023 23:14:26 -0500
Chuck Zmudzinski wrote:
> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:
> >> I think the change Michael suggests is very minimalistic: Move the if
> >> condition around xen_igd_reserve_slot(
On 13.01.2023 10:16, Julien Grall wrote:
> On 13/01/2023 08:54, Jan Beulich wrote:
>> On 13.01.2023 06:28, Penny Zheng wrote:
>>> xen/arch/x86/Kconfig |1 +
>>> xen/common/Kconfig|6 +
>>> xen/common/Makefile |2 +-
>
On 13.01.2023 00:20, Julien Grall wrote:
> On 04/01/2023 10:27, Jan Beulich wrote:
>> On 23.12.2022 13:22, Julien Grall wrote:
>>> On 22/12/2022 11:12, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
>>
On Fri, Jan 13, 2023 at 07:39:38AM +, Joan Bruguera wrote:
> Hi Peter,
>
> I tried your patches on both QEMU and my two (real) computers where
> s2ram with `retbleed=stuff` was failing and they wake up fine now.
Yay \o/
> However, I think some minor reviews are needed:
>
> (1) I got a build
On 13/01/2023 09:16, Jan Beulich wrote:
On 13.01.2023 00:15, Julien Grall wrote:
Hi,
On 04/01/2023 10:23, Jan Beulich wrote:
On 23.12.2022 12:31, Julien Grall wrote:
On 20/12/2022 15:30, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
From: Hongyan Xia
This avoids the assum
Hi,
On 13/01/2023 08:54, Jan Beulich wrote:
On 13.01.2023 06:28, Penny Zheng wrote:
xen/arch/x86/Kconfig |1 +
xen/common/Kconfig|6 +
xen/common/Makefile |2 +-
xen/include/xen/vmap.h| 93
On 13.01.2023 00:15, Julien Grall wrote:
> Hi,
>
> On 04/01/2023 10:23, Jan Beulich wrote:
>> On 23.12.2022 12:31, Julien Grall wrote:
>>> On 20/12/2022 15:30, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> This avoids the assumption that boot
On 13.01.2023 08:44, Xenia Ragiadakou wrote:
>
> On 1/12/23 14:37, Jan Beulich wrote:
>> On 12.01.2023 13:16, Jan Beulich wrote:
>>> On 04.01.2023 09:45, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2143,6 +2143,14 @@ static bool cf_c
On 13.01.2023 08:30, Xenia Ragiadakou wrote:
> On 1/12/23 14:16, Jan Beulich wrote:
>> On 04.01.2023 09:45, Xenia Ragiadakou wrote:
>>> @@ -250,6 +252,9 @@ struct hvm_function_table {
>>> /* Architecture function to setup TSC scaling ratio */
>>> void (*setup)(struct vcpu *v);
>
Hi Luca,
On 12/01/2023 10:54, Luca Fancellu wrote:
On 11 Jan 2023, at 17:27, Julien Grall wrote:
Hi Luca,
On 11/01/2023 14:38, Luca Fancellu wrote:
Add sve_vl_bits field to arch_domain and xen_arch_domainconfig
structure, to allow the domain to have an information about the
SVE feature and t
On 12.01.2023 18:07, Andrew Cooper wrote:
> On 12/01/2023 12:47 pm, Jan Beulich wrote:
>> On 10.01.2023 18:18, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -936,6 +936,9 @@ void cpu_init(void)
>>> write_debugreg(6, X86_DR6_DEFAULT);
>>>
On 13.01.2023 06:28, Penny Zheng wrote:
> xen/arch/x86/Kconfig |1 +
> xen/common/Kconfig|6 +
> xen/common/Makefile |2 +-
> xen/include/xen/vmap.h| 93 +-
I would like to take a look at these non
Hi Luca,
On 12/01/2023 10:46, Luca Fancellu wrote:
On 11 Jan 2023, at 17:16, Julien Grall wrote:
Hi Luca,
As this is an RFC, I will be mostly making general comments.
Hi Julien,
Thank you.
On 11/01/2023 14:38, Luca Fancellu wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/do
While c61a6f74f80e ("x86: enforce consistent cachability of MMIO
mappings") correctly converted one !mfn_valid() check there, two others
were wrongly left untouched: Both cachability control and log-dirty
tracking ought to be uniformly handled/excluded for all (non-)MMIO
ranges, not just ones quali
First of all the variable is meaningful only when an IOMMU is in use for
a guest. Qualify the check accordingly, like done elsewhere. Furthermore
the controlling command line option is supposed to take effect on VT-d
only. Since command line parsing happens before we know whether we're
going to use
While reviewing Xenia's change to iommu_snoop placement, I've
spotted a shortcoming in _sh_propagate(), fixing of which made
me notice (again) a 2nd kind of issue.
1: sanitize iommu_snoop usage
2: further correct MMIO handling in _sh_propagate()
Jan
Hi Luca,
On 12/01/2023 11:58, Luca Fancellu wrote:
On 11 Jan 2023, at 16:59, Julien Grall wrote:
On 11/01/2023 14:38, Luca Fancellu wrote:
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to im
1 - 100 of 105 matches
Mail list logo
