Hello, Jan!
On 30.08.21 16:04, Jan Beulich wrote:
Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
console) are associated with DomXEN, not Dom0. This means that while
looking for overlapping BARs such devices cannot be found on Dom0's
list of devices; DomXEN's list also
flight 164625 xen-4.11-testing real [real]
flight 164675 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164625/
http://logs.test-lab.xenproject.org/osstest/logs/164675/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 164630 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164630/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 77d5fa80246e8784f89e109ff9dadfeb7089ff85
baseline version:
ovmf
On Wed, 11 Aug 2021, Wei Chen wrote:
> Xen x86 has created a command line parameter "numa" as NUMA switch for
> user to turn on/off NUMA. As device tree based NUMA has been enabled
> for Arm, this parameter can be reused by Arm. So in this patch, we move
> this parameter to common.
>
>
On Wed, 11 Aug 2021, Wei Chen wrote:
> Everything is ready, we can remove the fake NUMA node and
> depends on device tree to create NUMA system.
>
> Signed-off-by: Wei Chen
> ---
> xen/arch/arm/numa.c| 45 ++
> xen/include/asm-arm/numa.h | 7 --
>
On Wed, 11 Aug 2021, Wei Chen wrote:
> After the previous patches preparations, numa_scan_nodes can be
> used by Arm and x86. So we move this function from x86 to common.
> As node_cover_memory will not be used cross files, we restore its
> static attribute in this patch.
>
> Signed-off-by: Wei
On Wed, 11 Aug 2021, Wei Chen wrote:
> Not only ACPU NUMA, but also Arm device tree based NUMA
> will use nodes_cover_memory to do sanity check. So we move
> this function from arch/x86 to common.
>
> Signed-off-by: Wei Chen
> ---
> xen/arch/x86/srat.c| 40
On Wed, 11 Aug 2021, Wei Chen wrote:
> We will reuse nodes_cover_memory for Arm to check its bootmem
> info. So we introduce two arch helpers to get memory map's
> entry number and specified entry's range:
> arch_get_memory_bank_number
> arch_get_memory_bank_range
>
> Depends above two
> From: Jan Beulich
> Sent: Monday, August 30, 2021 10:22 PM
>
> VT-d spec 3.2 converted this bit (back) to reserved. Since there's no
> use of it anywhere in the tree, simply rename it and adjust its comment.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> ---
branch xen-4.13-testing
xenbranch xen-4.13-testing
job test-amd64-amd64-dom0pvh-xl-intel
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On Wed, 11 Aug 2021, Wei Chen wrote:
> In this API, we scan whole device tree to parse CPU node id, memory
> node id and distance-map. Though early_scan_node will invoke has a
> handler to process memory nodes. If we want to parse memory node id
> in this handler, we have to embeded NUMA parse
On Wed, 11 Aug 2021, Wei Chen wrote:
> A NUMA aware device tree will provide a "distance-map" node to
> describe distance between any two nodes. This patch introduce a
> new helper to parse this distance map.
>
> Signed-off-by: Wei Chen
> ---
> xen/arch/arm/numa_device_tree.c | 67
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-dom0pvh-xl-intel
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
flight 164623 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164623/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
flight 164614 xen-unstable real [real]
flight 164663 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164614/
http://logs.test-lab.xenproject.org/osstest/logs/164663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, Aug 27, 2021 at 01:29:32PM -0700, Keith Busch wrote:
> On Fri, Aug 27, 2021 at 12:18:02PM -0700, Luis Chamberlain wrote:
> > @@ -479,13 +479,17 @@ int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl,
> > struct nvme_ns_head *head)
> > static void nvme_mpath_set_live(struct nvme_ns *ns)
> >
[ resending message to ensure delivery to the CCd mailing lists
post-subscription ]
Apologies for being late to this thread, but I hope to be able to
contribute to
this discussion in a meaningful way. I am grateful for the level of
interest in
this topic. I would like to draw your attention to
Apologies for being late to this thread, but I hope to be able to
contribute to
this discussion in a meaningful way. I am grateful for the level of
interest in
this topic. I would like to draw your attention to Argo as a suitable
technology for development of VirtIO's hypervisor-agnostic
On Mon, Aug 30, 2021 at 10:14:26PM +0200, Sergio Miguéns Iglesias wrote:
> Thanks again for you answers!
> I am lerning a lot from your replys and I really appreciate it. Should I
> make a v3 patch and split that one into 2 different patches or would it
> be confusing?
>
> I don't want to take
Never mind, it got accepted anyways, but I will 100% fix my commit
messages for my future patches.
I really appreciate your suggestions and the time you have put into
writing them. I will improve in my next commits :)
Sergio M. Iglesias.
On 21/08/30 11:29, Bjorn Helgaas wrote:
> On Mon, Aug 30,
Thanks again for you answers!
I am lerning a lot from your replys and I really appreciate it. Should I
make a v3 patch and split that one into 2 different patches or would it
be confusing?
I don't want to take more of your time with poor patches so I don't know
if I should resend this one.
flight 164649 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164649/
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
On Mon, Aug 30, 2021 at 07:53:05PM +0200, Sergio Miguéns Iglesias wrote:
> An unnecessary "__ref" annotation was removed from the
> "drivers/pci/xen_pcifront.c" file. The function where the annotation
> was used was "pcifront_backend_changed()", which does not call any
> functions annotated as
On 30.08.21 16:16, Jan Beulich wrote:
Hi Jan
On 29.08.2021 22:28, Oleksandr wrote:
On 16.08.21 10:33, Jan Beulich wrote:
On 14.08.2021 01:28, Oleksandr Tyshchenko wrote:
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -332,6 +332,11 @@ struct
On 30.08.21 19:53, Sergio Miguéns Iglesias wrote:
An unnecessary "__ref" annotation was removed from the
"drivers/pci/xen_pcifront.c" file. The function where the annotation
was used was "pcifront_backend_changed()", which does not call any
functions annotated as "__*init" nor "__*exit". This
flight 164601 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164601/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164526
test-armhf-armhf-libvirt 16
An unnecessary "__ref" annotation was removed from the
"drivers/pci/xen_pcifront.c" file. The function where the annotation
was used was "pcifront_backend_changed()", which does not call any
functions annotated as "__*init" nor "__*exit". This makes "__ref"
unnecessary since this annotation is
I can not thank you enough for the amount of time you must have spent
writing this response. I will look into those things in the following
days for sure! ( I have already started looking into the "__ref" stuff)
Thanks again for this,
Sergio M. Iglesias.
On 21/08/25 03:43, Bjorn Helgaas wrote:
>
Thanks a lot for your reply! I am sending a v2 patch to fix all the
issues.
Sergio M. Iglesias.
On 21/08/30 06:55, Juergen Gross wrote:
> On 30.08.21 00:14, Sergio Miguéns Iglesias wrote:
> > An unnecessary "__ref" annotation was removed from the
> > "drivers/pci/xen_pcifront.c" file. The
Both comment and message string associated with GNTST_no_device_space
suggest a connection to the IOMMU. A lack of maptrack handles has
nothing to do with that; it's unclear to me why commit 6213b696ba65
("Grant-table interface redone") introduced it this way. Introduce a
new error indicator.
There's no point checking ->dev_bus_addr when GNTMAP_device_map isn't
set (and hence the field isn't going to be consumed). And if there is a
mismatch, use the so far unused GNTST_bad_dev_addr error indicator - if
not here, where else would this (so far unused) value be used?
Signed-off-by: Jan
VT-d spec 3.2 converted this bit (back) to reserved. Since there's no
use of it anywhere in the tree, simply rename it and adjust its comment.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -46,8 +46,7 @@ typedef union {
On 8/30/21 9:46 AM, Jan Beulich wrote:
> On 30.08.2021 15:41, Daniel P. Smith wrote:
>> On 8/30/21 9:24 AM, Jan Beulich wrote:
>>> On 27.08.2021 16:06, Daniel P. Smith wrote:
On 8/26/21 4:13 AM, Jan Beulich wrote:
> On 05.08.2021 16:06, Daniel P. Smith wrote:
>> --- /dev/null
>>
On 30.08.2021 15:41, Daniel P. Smith wrote:
> On 8/30/21 9:24 AM, Jan Beulich wrote:
>> On 27.08.2021 16:06, Daniel P. Smith wrote:
>>> On 8/26/21 4:13 AM, Jan Beulich wrote:
On 05.08.2021 16:06, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/include/xsm/xsm-core.h
> @@ -0,0
On 8/30/21 9:24 AM, Jan Beulich wrote:
> On 27.08.2021 16:06, Daniel P. Smith wrote:
>> On 8/26/21 4:13 AM, Jan Beulich wrote:
>>> On 05.08.2021 16:06, Daniel P. Smith wrote:
--- /dev/null
+++ b/xen/include/xsm/xsm-core.h
@@ -0,0 +1,273 @@
+/*
+ * This file contains the
On 30.08.2021 14:11, Daniel P. Smith wrote:
> On 8/26/21 5:37 AM, Jan Beulich wrote:
>> On 05.08.2021 16:06, Daniel P. Smith wrote:
>>> config XSM_FLASK
>>> - def_bool y
>>> - prompt "FLux Advanced Security Kernel support"
>>> - depends on XSM
>>> - ---help---
>>> + bool "FLux Advanced
On 27.08.2021 16:16, Daniel P. Smith wrote:
> On 8/25/21 11:44 AM, Jan Beulich wrote:
>> On 05.08.2021 16:06, Daniel P. Smith wrote:
>>> The internal define flag is not used by any XSM module, removing the #ifdef
>>> leaving the generic event channel labeling as always present.
>>
>> With this
On 27.08.2021 16:06, Daniel P. Smith wrote:
> On 8/26/21 4:13 AM, Jan Beulich wrote:
>> On 05.08.2021 16:06, Daniel P. Smith wrote:
>>> --- /dev/null
>>> +++ b/xen/include/xsm/xsm-core.h
>>> @@ -0,0 +1,273 @@
>>> +/*
>>> + * This file contains the XSM hook definitions for Xen.
>>> + *
>>> + *
On 29.08.2021 22:28, Oleksandr wrote:
> On 16.08.21 10:33, Jan Beulich wrote:
>> On 14.08.2021 01:28, Oleksandr Tyshchenko wrote:
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -332,6 +332,11 @@ struct xen_arch_domainconfig {
>>>*/
>>> uint32_t
Passing byte granular values will not have the intended effect. Address
the immediate issue, but I don't think what we do is actually
sufficient: At least some devices allow access to their registers via
either I/O ports or MMIO. In such aliasing cases we'd need to protect
the MMIO range even when
Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
console) are associated with DomXEN, not Dom0. This means that while
looking for overlapping BARs such devices cannot be found on Dom0's
list of devices; DomXEN's list also needs to be scanned.
Signed-off-by: Jan Beulich
---
Leaving shadow setup just to the L1TF tasklet means running Dom0 on a
minimally acceptable shadow memory pool, rather than what normally
would be used (also, for example, for PVH). Populate the pool before
triggering the tasklet, on a best effort basis (again like done for
PVH).
Signed-off-by:
Assuming that the accounting for IOMMU page tables will also take care
of the P2M needs was wrong: dom0_paging_pages() can determine a far
higher value, high enough for the system to run out of memory while
setting up Dom0. Hence in the case of shared page tables the larger of
the two values needs
One of the changes comprising the fixes for XSA-378 disallows replacing
MMIO mappings by unintended (for this purpose) code paths. At least in
the case of PVH Dom0 hitting an RMRR covered by an E820 ACPI region,
this is too strict. Generally short-circuit requests establishing the
same kind of
One of the changes comprising the fixes for XSA-378 disallows replacing
MMIO mappings by unintended (for this purpose) code paths. This means we
need to be more careful about the mappings put in place in this range -
mappings should be created exactly once:
- iommu_hwdom_init() comes first; it
The code building PVH Dom0 made use of sequences of P2M changes
which are disallowed as of XSA-378. First of all population of the
first Mb of memory needs to be redone. Then, largely as a
workaround, checking introduced by XSA-378 needs to be slightly
relaxed.
Note that with these adjustments I
On 8/26/21 5:37 AM, Jan Beulich wrote:
> On 05.08.2021 16:06, Daniel P. Smith wrote:
>> The XSM facilities are always in use by Xen with the facade of being able to
>> turn XSM on and off. This option is in fact about allowing the selection of
>> which policies are available and which are used at
Sorry for the delayed answer, but I look at the vmap_pfn usage in the
previous version and tried to come up with a better version. This
mostly untested branch:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hyperv-vmap
get us there for swiotlb and the channel infrastructure
flight 164577 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 8 xen-boot fail REGR. vs. 163761
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年8月30日 17:52
> To: Wei Chen
> Cc: Bertrand Marquis ; Julien Grall
> ; xen-devel@lists.xenproject.org; sstabell...@kernel.org
> Subject: Re: [XEN RFC PATCH 37/40] xen: introduce an arch helper to do
> NUMA init failed fallback
On 27.08.2021 16:46, Jan Beulich wrote:
> On 27.08.2021 15:29, Jan Beulich wrote:
>> On 27.08.2021 08:52, osstest service owner wrote:
>>> flight 164495 xen-4.15-testing real [real]
>>> flight 164509 xen-4.15-testing real-retest [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/164495/
On 30.07.21 12:38, Juergen Gross wrote:
Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen
On 25.08.21 13:41, zhaoxiao wrote:
Since we have the nice helpers pr_err() and pr_warn(), use them instead
of raw printk().
Signed-off-by: zhaoxiao
Pushed to xen/tip.git for-linus-5.15 with a small fix (moved the
"#define pr_fmt" before the first #include in order to avoid
build warnings due
On 25.08.21 08:24, CGEL wrote:
From: Jing Yangyang
Use BUG_ON instead of a if condition followed by BUG.
Generated by: scripts/coccinelle/misc/bugon.cocci
Reported-by: Zeal Robot
Signed-off-by: Jing Yangyang
Pushed to xen/tip.git for-linus-5.15
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
On 28.08.2021 05:45, Wei Chen wrote:
>> From: Xen-devel On Behalf Of Wei
>> Chen
>> Sent: 2021年8月28日 11:09
>>
>>> From: Julien Grall
>>> Sent: 2021年8月27日 22:30
>>>
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -140,3 +140,16 @@ int __init
branch xen-4.11-testing
xenbranch xen-4.11-testing
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
Le lun. 30 août 2021 à 10:31, Juergen Gross a écrit :
>
> On 28.08.21 11:07, Fabrice Fontaine wrote:
> > Don't assume tv_sec is a unsigned long, it is 64 bits on NetBSD 32 bits.
> > Use %jd and cast to (intmax_t) instead
> >
> > Signed-off-by: Fabrice Fontaine
> > ---
> >
On 28.08.21 11:07, Fabrice Fontaine wrote:
Don't assume tv_sec is a unsigned long, it is 64 bits on NetBSD 32 bits.
Use %jd and cast to (intmax_t) instead
Signed-off-by: Fabrice Fontaine
---
tools/libs/light/libxl_domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
flight 164603 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164603/
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
flight 164564 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164564/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 8 xen-boot fail REGR. vs. 163759
60 matches
Mail list logo
