Hi, julien
> -Original Message-
> From: Julien Grall
> Sent: Saturday, April 9, 2022 5:26 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: nd ; Stefano Stabellini ; Bertrand
> Marquis ; Volodymyr Babchuk
>
> Subject: Re: [PATCH v1 08/13] xen/arm: destroy static shared memory w
Hi Jan,
On 2022/4/19 17:18, Jan Beulich wrote:
On 18.04.2022 11:07, Wei Chen wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1889,7 +1889,7 @@ void __init end_boot_allocator(void)
}
nr_bootmem_regions = 0;
-if ( !dma_bitsize && (num_online_nodes() > 1)
Hi Jiamei,
On 2022/4/19 17:13, Jiamei Xie wrote:
Hi Wei,
-Original Message-
From: Xen-devel On Behalf Of
Wei Chen
Sent: 2022年4月18日 17:07
To: --to=xen-devel@lists.xenproject.org; xen-devel@lists.xenproject.org
Cc: nd ; Wei Chen ; Stefano Stabellini
; Julien Grall ; Bertrand Marquis
; V
Hi Stefano,
On 2022/4/21 8:25, Stefano Stabellini wrote:
On Mon, 18 Apr 2022, Wei Chen wrote:
x86 is using compiler feature testing to decide EFI
build enable or not. When EFI build is disabled, x86
will use a efi/stub.c file to replace efi/runtime.c
for build objects. Following this idea, we i
flight 169585 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 20.04.22 20:44, Boris Ostrovsky wrote:
On 4/20/22 11:09 AM, Juergen Gross wrote:
+/*
+ * xenbus_setup_ring
+ * @dev: xenbus device
+ * @vaddr: pointer to starting virtual address of the ring
+ * @nr_pages: number of pages to be granted
+ * @grefs: grant reference array to be filled in
+ *
+
This serie introduces a feature for Xen to create cpu pools at boot time, the
feature is enabled using a configurable that is disabled by default.
The boot time cpupool feature relies on the device tree to describe the cpu
pools.
Another feature is introduced by the serie, the possibility to assign
Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
between cpupools, cpu hotplug, destroying cpupools, shutdown of the host,
might not work in a sane way.
Signed-off-by: Luca Fancellu
Reviewed-by: Juergen Gross
---
Changes in v8:
- Add R-by (Juergen)
Changes in v7:
- new pa
With the introduction of boot time cpupools, Xen can create many
different cpupools at boot time other than cpupool with id 0.
Since these newly created cpupools can't have an
entry in Xenstore, create the entry using xen-init-dom0
helper with the usual convention: Pool-.
Given the change, remove
Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.
Signed-off-by: Luca Fancellu
Reviewed-by: Juergen Gross
---
Changes in v8:
- no changes
Changes in v7:
- no changes
Changes in v6:
- add R-
Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.
Add member to the xen_domctl_createdomain public interface so the
XEN
Add a static function to retrieve the scheduler pointer using the
scheduler name.
Add a public function to retrieve the scheduler id by the scheduler
name that makes use of the new static function.
Take the occasion to replace open coded scheduler search with the
new static function in scheduler_
Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.
With this commit it is possible to allocate a different scheduler for
Introduce a way to create different cpupools at boot time, this is
particularly useful on ARM big.LITTLE system where there might be the
need to have different cpupools for each type of core, but also
systems using NUMA can have different cpu pools for each node.
The feature on arm relies on a spe
On 20.04.2022 20:01, Andrew Cooper wrote:
> On 20/04/2022 18:49, Andrew Cooper wrote:
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2355562119
>>
>> ld: prelink.o: in function `vtd_setup':
>> drivers/passthrough/vtd/iommu.c:(.init.text+0x219f6): undefined
>> reference to `opt_hap_2mb'
flight 169586 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 20.04.22 18:12, Boris Ostrovsky wrote:
On 4/20/22 5:25 AM, Juergen Gross wrote:
@@ -569,7 +645,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
wait_for_completion(&pending_req->tmr_done);
err = (se_cmd->se_tmr_req->response == TMR_FUNCTION_COMPLETE) ?
-
flight 169581 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169581/
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 169587 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169587/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 21.04.2022 00:28, Daniel P. Smith wrote:
> There are now instances where internal hypervisor logic needs to make resource
> allocation calls that are protectd by XSM checks. The internal hypervisor
> logic
> is represented a number of system domains which by designed are represented by
> non-pr
On 21.04.2022 00:28, Daniel P. Smith wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -168,7 +168,7 @@ static int cf_check flask_domain_alloc_security(struct
> domain *d)
> switch ( d->domain_id )
> {
> case DOMID_IDLE:
> -dsec->sid = SECINITSID_XEN;
>
On 20.04.2022 18:03, Juergen Gross wrote:
> On 20.04.22 17:56, Andrew Cooper wrote:
>> When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL
>> pointer. It isn't really correct for processing of XEN_DOMCTL_gdbsx_* to
>> fall
>> into the default case when compiled out.
>>
>> Signe
On 31.03.2022 11:27, Roger Pau Monne wrote:
> Use the logic to set shadow SPEC_CTRL values in order to implement
> support for VIRT_SPEC_CTRL (signaled by VIRT_SSBD CPUID flag) for HVM
> guests. This includes using the spec_ctrl vCPU MSR variable to store
> the guest set value of VIRT_SPEC_CTRL.SSB
On 31.03.2022 11:27, Roger Pau Monne wrote:
> Allow HVM guests untrapped access to MSR_VIRT_SPEC_CTRL if the
> hardware has support for it. This requires adding logic in the
> vm{entry,exit} paths for SVM in order to context switch between the
> hypervisor value and the guest one. The added handler
On 21/04/2022 10:26, Jan Beulich wrote:
> On 20.04.2022 18:03, Juergen Gross wrote:
>> On 20.04.22 17:56, Andrew Cooper wrote:
>>> When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL
>>> pointer. It isn't really correct for processing of XEN_DOMCTL_gdbsx_* to
>>> fall
>>> into
On 31.03.2022 11:27, Roger Pau Monne wrote:
> Expose VIRT_SSBD to guests if the hardware supports setting SSBD in
> the LS_CFG MSR (a.k.a. non-architectural way). Different AMD CPU
> families use different bits in LS_CFG, so exposing VIRT_SPEC_CTRL.SSBD
> allows for an unified way of exposing SSBD
On Wed, Apr 20, 2022 at 06:28:33PM -0400, Daniel P. Smith wrote:
> There are now instances where internal hypervisor logic needs to make resource
> allocation calls that are protectd by XSM checks. The internal hypervisor
> logic
> is represented a number of system domains which by designed are re
flight 169588 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 20.04.22 18:13, Boris Ostrovsky wrote:
Just a couple of nits.
On 4/20/22 5:25 AM, Juergen Gross wrote:
-static int scsifront_ring_drain(struct vscsifrnt_info *info)
+static int scsifront_ring_drain(struct vscsifrnt_info *info,
+ unsigned int *eoiflag)
{
- struct vscsiif_
The retaining of .note.* in a PT_NOTE segment requires a matching
program header to be present in the first place. Drop the respective
conditional and adjust mkelf32 to deal with (ignore) the potentially
present but empty extra segment (but have the new code be generic by
dropping any excess traili
From: David Vrabel
Heap pages can only be safely allocated and freed with interuupts
enabled as they may require a TLB flush which will send IPIs.
Normally spinlock debugging would catch calls from the incorrect
context, but not from stop_machine_run() action functions as these are
called with s
On 21/04/2022 11:40, Jan Beulich wrote:
> The retaining of .note.* in a PT_NOTE segment requires a matching
> program header to be present in the first place. Drop the respective
> conditional and adjust mkelf32 to deal with (ignore) the potentially
> present but empty extra segment (but have the n
flight 169589 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169577 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169577/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169565
test-amd64-amd64-qemuu-nested-amd 20
Hi Arm/SMMU experts,
Scenario :- I am trying to assign a device (eg mmc) to a guest which
uses smmu. I start the guest using "xl create -c ...". It works fine for
the first time. I am able to access the device.
Now, when I destroy the guest and create again, I see this issue
(XEN) smmu: /axi
flight 169590 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169590/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 21.04.2022 12:43, David Vrabel wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -984,6 +984,8 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> console_init_postirq();
>
> +system_state = SYS_STATE_smp_boot
> +
> do_presmp_initcalls();
>
>
On 21.04.2022 13:12, Ayan Kumar Halder wrote:
> Hi Arm/SMMU experts,
>
> Scenario :- I am trying to assign a device (eg mmc) to a guest which
> uses smmu. I start the guest using "xl create -c ...". It works fine for
> the first time. I am able to access the device.
>
> Now, when I destroy the
On 21/04/2022 12:38, Jan Beulich wrote:
On 21.04.2022 12:43, David Vrabel wrote:
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -984,6 +984,8 @@ void __init start_xen(unsigned long boot_phys_offset,
console_init_postirq();
+system_state = SYS_STATE_smp_boot
+
flight 169592 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 21.04.2022 14:23, David Vrabel wrote:
> On 21/04/2022 12:38, Jan Beulich wrote:
>> On 21.04.2022 12:43, David Vrabel wrote:
>>> --- a/xen/arch/arm/setup.c
>>> +++ b/xen/arch/arm/setup.c
>>> @@ -984,6 +984,8 @@ void __init start_xen(unsigned long boot_phys_offset,
>>>
>>> console_init_po
On 20.04.2022 16:13, Andrew Cooper wrote:
> From: Bobby Eshleman
>
> debugger_trap_entry() is unrelated to the other contents of debugger.h. It is
> a no-op for everything other than #DB/#BP, and for those it invokes guest
> debugging (CONFIG_GDBSX) not host debugging (CONFIG_CRASH_DEBUG).
>
>
On 4/21/22 05:20, Jan Beulich wrote:
> On 21.04.2022 00:28, Daniel P. Smith wrote:
>> There are now instances where internal hypervisor logic needs to make
>> resource
>> allocation calls that are protectd by XSM checks. The internal hypervisor
>> logic
>> is represented a number of system domain
On 20.04.2022 16:13, Andrew Cooper wrote:
> From: Bobby Eshleman
>
> debug.c contains only dbg_rw_mem(). Rename it to gdbsx.c.
>
> Move gdbsx_guest_mem_io(), and the prior setup of iop->remain, from domctl.c
> to gdbsx.c, merging it with dbg_rw_mem().
>
> Signed-off-by: Bobby Eshleman
> Signe
On 20.04.2022 16:13, Andrew Cooper wrote:
> domain_pause_for_debugger() is guest debugging (CONFIG_GDBSX) not host
> debugging (CONFIG_CRASH_DEBUG).
>
> Move it into the new gdbsx.c to drop the (incorrect) ifdefary, and provide a
> static inline in the !CONFIG_GDBSX case so callers can optimise aw
On 20.04.2022 16:13, Andrew Cooper wrote:
> common/gdbstub.c wants struct gdb_context but only gets it transitively
> through asm/debugger.h. None of */gdbstub.c should include asm/debugger.h so
> include xen/gdbstub.h instead.
>
> Forward declare struct cpu_user_regs in xen/gdbstub.h so it doesn
On 20.04.2022 16:13, Andrew Cooper wrote:
> * Remove inappropriate semicolon from debugger_trap_immediate()
> * Try to explain what debugger_trap_fatal() is doing, and write it in a more
>legible way.
> * Drop unecessary includes. This includes common/domain.c which doesn't use
>any deb
On 20.04.2022 16:13, Andrew Cooper wrote:
> From: Bobby Eshleman
>
> With all the non-CONFIG_CRASH_DEBUG functionality moved elsewhere, split
> x86/debugger.h in two, with the stubs and explanation moved to xen/debugger.h.
>
> In particular, this means that arches only need to provide an $arch/d
Allow disabling (masking) IO-APIC pins set to edge trigger mode. This
is required in order to safely migrate such interrupts between CPUs,
as the write to update the IO-APIC RTE (or the IRTE) is not done
atomically, so there's a window where there's a mismatch between the
destination CPU and the v
Hello,
Following series attempts to solve the issue with IO-APIC edge triggered
interrupts seeing an inconsistent RTE or IRTE when injected while being
migrated.
It's currently RFC because some patches have post commit message notes,
and because I'm not sure if patch 1 is really needed. I origin
So that the remapping entry can be updated atomically when possible.
Doing such update atomically will avoid Xen having to mask the IO-APIC
pin prior to performing any interrupt movements (ie: changing the
destination and vector fields), as the interrupt remapping entry is
always consistent.
This
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/include/asm/io_apic.h | 57 --
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/xen/arch/x86/include/asm/io_apic.h
b/xen/arch/x86/include/asm/io_apic.h
index ef0878b09e..a55
Hi Ayan,
> On 21 Apr 2022, at 12:12 pm, Ayan Kumar Halder
> wrote:
>
> Hi Arm/SMMU experts,
>
> Scenario :- I am trying to assign a device (eg mmc) to a guest which uses
> smmu. I start the guest using "xl create -c ...". It works fine for the first
> time. I am able to access the device.
>
>
Do not allow to write to RTE registers using io_apic_write and instead
require changes to RTE to be performed using ioapic_write_entry.
This is in preparation for passing the full contents of the RTE to the
IOMMU interrupt remapping handlers, so remapping entries for IO-APIC
RTEs can be updated at
When writing an IO-APIC RTE entry make sure incoming interrupts never
see a partially updated entry, by masking the pin while doing the
update when necessary. Add some logic to attempt to limit the number
of writes.
With the masking now handled by __ioapic_write_entry itself when
necessary, we ca
Doing so matches existing VT-d behavior, and does prevent having to
disable the remapping entry or mask the IO-APIC pin prior to being
updated, as the remap entry content is always consistent.
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/amd/iommu_intr.c | 31 +-
Hello everyone,
The polling has now closed. Thank you everyone who participated. The best
time turned out to be 4pm British Time on Thursday. I know this is hard for
some people, but it was always unlikely to find a time which suited everyone.
Peace,
-George
> On Apr 7, 2022, at 10:46 AM,
On 20.04.2022 20:01, Andrew Cooper wrote:
> On 20/04/2022 18:49, Andrew Cooper wrote:
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2355562119
>>
>> ld: prelink.o: in function `vtd_setup':
>> drivers/passthrough/vtd/iommu.c:(.init.text+0x219f6): undefined
>> reference to `opt_hap_2mb'
On 4/21/22 05:53, Roger Pau Monné wrote:
> On Wed, Apr 20, 2022 at 06:28:33PM -0400, Daniel P. Smith wrote:
>> There are now instances where internal hypervisor logic needs to make
>> resource
>> allocation calls that are protectd by XSM checks. The internal hypervisor
>> logic
>> is represented
flight 169593 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Just the two remaining patches, with the only change being a would-be-
build fix to Arm code which cannot be compiled in the first place.
1: PCI: replace stray uses of PCI_{DEVFN,BDF}2()
2: PCI: replace "secondary" flavors of PCI_{DEVFN,BDF,SBDF}()
Jan
There's no good reason to use these when we already have a pci_sbdf_t
type object available. This extends to the use of PCI_BUS() in
pci_ecam_map_bus() as well.
No change to generated code (with gcc11 at least, and I have to admit
that I didn't expect compilers to necessarily be able to spot the
o
At their use sites the numeric suffixes are at least odd to read, first
and foremost for PCI_DEVFN2() where the suffix doesn't even match the
number of arguments. Make use of count_args() such that a single flavor
each suffices (leaving aside helper macros, which aren't supposed to be
used from the
On 4/21/22 05:22, Jan Beulich wrote:
> On 21.04.2022 00:28, Daniel P. Smith wrote:
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -168,7 +168,7 @@ static int cf_check flask_domain_alloc_security(struct
>> domain *d)
>> switch ( d->domain_id )
>> {
>> case DOMID_
On 21/04/2022 15:26, Jan Beulich wrote:
There's no good reason to use these when we already have a pci_sbdf_t
type object available. This extends to the use of PCI_BUS() in
pci_ecam_map_bus() as well.
No change to generated code (with gcc11 at least, and I have to admit
that I didn't expect comp
On 21/04/2022 15:27, Jan Beulich wrote:
At their use sites the numeric suffixes are at least odd to read, first
and foremost for PCI_DEVFN2() where the suffix doesn't even match the
number of arguments. Make use of count_args() such that a single flavor
each suffices (leaving aside helper macros,
On Thu, Apr 21, 2022 at 10:14:18AM -0400, Daniel P. Smith wrote:
> On 4/21/22 05:53, Roger Pau Monné wrote:
> > On Wed, Apr 20, 2022 at 06:28:33PM -0400, Daniel P. Smith wrote:
> >> There are now instances where internal hypervisor logic needs to make
> >> resource
> >> allocation calls that are p
Hi, Julien Grall.
Thank you! After thinking about it, I agree that the patch I suggested
is not a good way to go.
> I don't understand how this is related to adding extra cflags. Can you
> clarify it?
https://www.youtube.com/watch?v=RPgYinVQUgw
I took a short video of debugging through qemu and
It doesn't seem necessary to do that calculation of order shift again.
Signed-off-by: Paran Lee
---
xen/arch/arm/p2m.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1d1059f7d2..533afc830a 100644
--- a/xen/arch/arm/p2m.c
On Thu, Apr 21, 2022 at 11:50:16AM +0200, Jan Beulich wrote:
> On 31.03.2022 11:27, Roger Pau Monne wrote:
> > Expose VIRT_SSBD to guests if the hardware supports setting SSBD in
> > the LS_CFG MSR (a.k.a. non-architectural way). Different AMD CPU
> > families use different bits in LS_CFG, so expos
flight 169584 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169584/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169573
test-armhf-armhf-libvirt 16 sav
On 21.04.2022 17:21, Roger Pau Monné wrote:
> On Thu, Apr 21, 2022 at 11:50:16AM +0200, Jan Beulich wrote:
>> On 31.03.2022 11:27, Roger Pau Monne wrote:
>>> Expose VIRT_SSBD to guests if the hardware supports setting SSBD in
>>> the LS_CFG MSR (a.k.a. non-architectural way). Different AMD CPU
>>>
On 21.04.22 12:13, Juergen Gross wrote:
On 20.04.22 18:13, Boris Ostrovsky wrote:
Just a couple of nits.
On 4/20/22 5:25 AM, Juergen Gross wrote:
-static int scsifront_ring_drain(struct vscsifrnt_info *info)
+static int scsifront_ring_drain(struct vscsifrnt_info *info,
+ unsign
Now that `make MAP` might rebuild $(TARGET), it needs removing from
no-dot-config-targets.
Otherwise the build eventually fails with:
CPP arch/x86/asm-macros.i
arch/x86/asm-macros.c:1:10: fatal error: asm/asm-defns.h: No such file or
directory
1 | #include
| ^~
On 21.04.2022 18:00, Andrew Cooper wrote:
> Now that `make MAP` might rebuild $(TARGET), it needs removing from
> no-dot-config-targets.
Which raises the question whether the MAP target originally was
meant to be used only on an already built tree, which would
explain the missing dependency that y
On 21/04/2022 17:09, Jan Beulich wrote:
> On 21.04.2022 18:00, Andrew Cooper wrote:
>> Now that `make MAP` might rebuild $(TARGET), it needs removing from
>> no-dot-config-targets.
> Which raises the question whether the MAP target originally was
> meant to be used only on an already built tree, wh
Hi Rahul,
On 21/04/2022 14:21, Rahul Singh wrote:
Hi Ayan,
> On 21 Apr 2022, at 12:12 pm, Ayan Kumar Halder
wrote:
>
> Hi Arm/SMMU experts,
>
> Scenario :- I am trying to assign a device (eg mmc) to a guest which
uses smmu. I start the guest using "xl create -c ...". It works fine
for the
Hi Ayan,
> On 21 Apr 2022, at 5:44 pm, Ayan Kumar Halder
> wrote:
>
> Hi Rahul,
>
> On 21/04/2022 14:21, Rahul Singh wrote:
>> Hi Ayan,
>>
>> > On 21 Apr 2022, at 12:12 pm, Ayan Kumar Halder
>> > wrote:
>> >
>> > Hi Arm/SMMU experts,
>> >
>> > Scenario :- I am trying to assign a device (eg
flight 169594 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169594/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 21/04/2022 14:02, Jan Beulich wrote:
> On 20.04.2022 16:13, Andrew Cooper wrote:
>> From: Bobby Eshleman
>>
>> debugger_trap_entry() is unrelated to the other contents of debugger.h. It
>> is
>> a no-op for everything other than #DB/#BP, and for those it invokes guest
>> debugging (CONFIG_GDB
On 21/04/2022 14:06, Jan Beulich wrote:
> On 20.04.2022 16:13, Andrew Cooper wrote:
>> From: Bobby Eshleman
>>
>> debug.c contains only dbg_rw_mem(). Rename it to gdbsx.c.
>>
>> Move gdbsx_guest_mem_io(), and the prior setup of iop->remain, from domctl.c
>> to gdbsx.c, merging it with dbg_rw_mem(
Hi Stefano,
> On 20 Apr 2022, at 11:46 pm, Stefano Stabellini
> wrote:
>
> On Wed, 20 Apr 2022, Rahul Singh wrote:
>>> On 20 Apr 2022, at 3:36 am, Stefano Stabellini
>>> wrote:
> Then there is xen_swiotlb_init() which allocates some memory for
> swiotlb-xen at boot. It could lower the
On 20/04/2022 07:27, Jan Beulich wrote:
> On 20.04.2022 08:22, Juergen Gross wrote:
>> On 20.04.22 08:11, Jan Beulich wrote:
>>> On 20.04.2022 07:57, Juergen Gross wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -341,8 +341,17 @@ struct domain_iommu {
/*
On 20/04/2022 06:57, Juergen Gross wrote:
> Today iommu_do_domctl() is being called from arch_do_domctl() in the
> "default:" case of a switch statement. This has led already to crashes
> due to unvalidated parameters.
>
> Fix that by moving the call of iommu_do_domctl() to the main switch
> statem
flight 169596 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169596/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169597 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169597/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 20/04/2022 06:52, Jan Beulich wrote:
> On 19.04.2022 18:06, Andrew Cooper wrote:
>> On 19/04/2022 16:52, Juergen Gross wrote:
>>> On 19.04.22 17:48, Andrew Cooper wrote:
On 19/04/2022 10:39, Jan Beulich wrote:
> Besides the reporter's issue of hitting a NULL deref when
> !CONFIG_GDB
flight 169591 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169591/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail pass in 169577
test-amd64-i386-xl-qemut-debianh
flight 169598 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169598/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169599 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 4/21/22 4:40 AM, Juergen Gross wrote:
On 20.04.22 18:12, Boris Ostrovsky wrote:
On 4/20/22 5:25 AM, Juergen Gross wrote:
@@ -569,7 +645,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
wait_for_completion(&pending_req->tmr_done);
err = (se_cmd->se_tmr
On 4/19/22 7:43 PM, Alaa Mohamed wrote:
kmap() is being deprecated and these usages are all local to the thread
so there is no reason kmap_local_page() can't be used.
Replace kmap() calls with kmap_local_page().
Signed-off-by: Alaa Mohamed
Applied to for-linus-5.18. (Juergen, I kept your
On Thu, 21 Apr 2022, Wei Chen wrote:
> Hi Stefano,
>
> On 2022/4/21 8:25, Stefano Stabellini wrote:
> > On Mon, 18 Apr 2022, Wei Chen wrote:
> > > x86 is using compiler feature testing to decide EFI
> > > build enable or not. When EFI build is disabled, x86
> > > will use a efi/stub.c file to repl
flight 169600 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169600/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Thu, 21 Apr 2022, Rahul Singh wrote:
> > On 20 Apr 2022, at 11:46 pm, Stefano Stabellini
> > wrote:
> > On Wed, 20 Apr 2022, Rahul Singh wrote:
> >>> On 20 Apr 2022, at 3:36 am, Stefano Stabellini
> >>> wrote:
> > Then there is xen_swiotlb_init() which allocates some memory for
> > s
flight 169595 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169595/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169584
test-armhf-armhf-libvirt 16 sav
flight 169602 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Thu, 21 Apr 2022, Michal Orzel wrote:
> On 21.04.2022 01:31, Stefano Stabellini wrote:
> >
> > Oops, yes I did. Well spotted. Just sending this one update here.
> >
> >
> > ---
> > gitlab-ci: add an ARM32 qemu-based smoke test
> >
> > Add a minimal ARM32 smoke test based on qemu-system-arm,
On Fri, 22 Apr 2022, Paran Lee wrote:
> It doesn't seem necessary to do that calculation of order shift again.
>
> Signed-off-by: Paran Lee
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/p2m.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/a
On Wed, 20 Apr 2022, Paran Lee wrote:
> GCC with "-g -Wall -Wextra" option throws warning message as below:
>
> error: comparison of integer expressions of different signedness:
> ‘int’ and ‘unsigned int’ [-Werror=sign-compare]
>
> Silence the warning by correcting the integer type.
>
> Signed-
1 - 100 of 118 matches
Mail list logo
