On Wed, Jan 06, 2021 at 11:41:20AM +0800, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes in the device tree.
>
> Signed-off-by: Claire Chang
> ---
> include/linux/device.h | 4 ++
> include/linux/swiotlb.h | 7 +-
>
flight 158191 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158134
test-armhf-a
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the device tree.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 24 +
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 21 +
drivers/of/device.c | 4
drivers/of/of_private.h | 5 +
3 fil
Added a new struct, io_tlb_mem, as the IO TLB memory pool descriptor and
moved relevant global variables into that struct.
This will be useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
arch/powerpc/platforms/pseries/svm.c | 4 +-
drivers/xen/swiotlb-xen.c
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes in the device tree.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 ++
include/linux/swiotlb.h | 7 +-
kernel/dma/Kconfig | 1 +
kernel/dma/swiotlb.c| 144 ++
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against
the DMA overwriting buffer contents at unexpected times. However, to
protect against general data leakage and system memory corruption, the
system
Add the functions, swiotlb_alloc and swiotlb_free to support the
memory allocation from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 6 ++
kernel/dma/direct.c | 12 +++
kernel/dma/swiotlb.c| 171 +---
3 files change
flight 158179 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158179/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158134
test-armhf-a
flight 158162 qemu-mainline real [real]
flight 158184 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158162/
http://logs.test-lab.xenproject.org/osstest/logs/158184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 158181 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158181/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 20b292d0cdf7dce58d824fdf9ab1613c2a1ad2ec
baseline version:
ovmf 4ad1bd63b28ca103eba21
Hi all,
Thursday Jan 7 at 4PM UK time / 8AM California time we are going to have
a Xen Community Call.
You are welcome to suggest agenda items by replying to this email or by
adding them to this page:
https://cryptpad.fr/pad/#/2/pad/edit/OPN55rXaOncupuWuHxtddzWJ/
I prepopulated the page with ite
flight 158174 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158174/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158134
test-armhf-a
From: David Woodhouse
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().
We tend to get away with this on Xen versions below
Fix various breakages with INTX/GSI event channel interrupt delivery,
and add a command line option to test it so that it hopefully doesn't
get so broken again.
Karim attempted to rip this out in 2017 but put it back because it's still
necessary with older versions of Xen. This fixes it properly,
From: David Woodhouse
With INTX or GSI delivery, Xen uses the event channel structures of CPU0.
If the interrupt gets handled by Linux on a different CPU, then no events
are seen as pending. Rather than introducing locking to allow other CPUs
to process CPU0's events, just ensure that the PCI in
From: David Woodhouse
Only the IPI-related functions in the smp_ops should be conditional
on the vector callback being available. The rest should still happen:
• xen_hvm_smp_prepare_boot_cpu()
This function does two things, both of which should still happen if
there is no vector callback
From: David Woodhouse
In the case where xen_have_vector_callback is false, we still register
the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
though they aren't going to be used. Stop doing that.
Signed-off-by: David Woodhouse
---
arch/x86/xen/enlighten_hvm.c | 4 ++--
1 file
From: David Woodhouse
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors,
because there are guest kernels still in active use which us
In order to use the pre-built test-artifacts/qemu-system-aarch64 binary
for our tests, first we need to import it into the pipeline. Let's do
that the same way we did it for the kernel and Alpine Linux filesystem:
by creating a special job for it.
Signed-off-by: Stefano Stabellini
---
automation
Instead apt-get'ing Debian's qemu-system-aarch64, simply use the
provided QEMU binary under binaries.
Signed-off-by: Stefano Stabellini
---
automation/scripts/qemu-alpine-arm64.sh | 12 +---
automation/scripts/qemu-smoke-arm64.sh | 15 +++
2 files changed, 12 insertions(+),
Currently we are using Debian's qemu-system-aarch64 for our tests.
However, sometimes it crashes. It is hard to debug and even harder to
apply any fixes to it.
Instead, build our own QEMU as one of our test-artifacts, which are only
built once, then imported into each pipeline via phony jobs.
Sig
Hi all,
Currently we are using Debian's qemu-system-aarch64 for our tests.
However, sometimes it crashes. See for instance
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/939556527. It
is hard to debug and even harder to apply any fixes to it.
Instead, build our own QEMU as one of our te
On Dienstag, 5. Januar 2021 13:00:34 CET Wei Liu wrote:
> On Thu, Dec 24, 2020 at 08:02:37PM +0100, Hans van Kranenburg wrote:
> > Hi,
> >
> > On 12/23/20 5:56 PM, Maximilian Engelhardt wrote:
> > > check if a GNU date that supports the '-u -d @...' options and syntax or
> > > a BSD date are avail
On Tue, 5 Jan 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 05/01/2021 18:44, Stefano Stabellini wrote:
> > On Tue, 5 Jan 2021, André Przywara wrote:
> > > On 05/01/2021 16:06, Julien Grall wrote:
> > > > (+ Ian and Andre)
> > > >
> > > > Hi Bertrand,
> > > >
> > > > On IRC, Ian pointed out tha
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index c428fd16ce..fc7b2a4102 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1764
flight 158168 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158168/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158134
test-armhf-a
On 05/01/2021 19:05, Stefano Stabellini wrote:
MVFR2 is not available on arm32. Don't try to read it. Make MVFR2 arm64
only.
Not really, MVFR2 is allocated when running in AArch32 mode on Armv8. It
just doesn't exist on Armv7. See my answer your previous e-mail for more
details.
Fixes:
Hi Stefano,
On 05/01/2021 18:44, Stefano Stabellini wrote:
On Tue, 5 Jan 2021, André Przywara wrote:
On 05/01/2021 16:06, Julien Grall wrote:
(+ Ian and Andre)
Hi Bertrand,
On IRC, Ian pointed out that the smoke test was failing on Cubietruck.
The only patches because the last success and th
MVFR2 is not available on arm32. Don't try to read it. Make MVFR2 arm64
only.
Fixes: 9cfdb489af81 ("xen/arm: Add ID registers and complete cpuinfo")
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/cpufeature.c| 2 ++
xen/include/asm-arm/cpufeature.h | 2 +-
2 files changed, 3 insertio
On Tue, 5 Jan 2021, André Przywara wrote:
> On 05/01/2021 16:06, Julien Grall wrote:
> > (+ Ian and Andre)
> >
> > Hi Bertrand,
> >
> > On IRC, Ian pointed out that the smoke test was failing on Cubietruck.
> > The only patches because the last success and the failure are your series.
> >
> > Th
Modify hvm_pirq_eoi to always EOI the interrupt if required, instead
of not doing such EOI if the interrupt is routed through the vIO-APIC
and the entry is masked at the time the EOI is performed.
Further unmask of the vIO-APIC pin won't EOI the interrupt, and thus
the guest OS has to wait for the
flight 158165 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158165/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4ad1bd63b28ca103eba21e383c4375a3a91080cf
baseline version:
ovmf 4e511554872c318f8bce1
flight 158146 xen-unstable real [real]
flight 158167 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158146/
http://logs.test-lab.xenproject.org/osstest/logs/158167/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
From: Paul Durrant
This patch modifies libxlu_pci_parse_spec_string() to parse the new 'name'
parameter of PCI_SPEC_STRING detailed in the updated documention in
xl-pci-configuration(5) and populate the 'name' field of 'libxl_device_pci'.
If the 'name' field is non-NULL then both libxl_device_pc
From: Paul Durrant
Since assignable devices can be named, a subsequent patch will support use
of a PCI_SPEC_STRING containing a 'name' parameter instead of a 'bdf'. In
this case the name will be used to look up the 'bdf' in the list of assignable
(or assigned) devices.
Signed-off-by: Paul Durran
From: Paul Durrant
With this patch applied 'xl pci-assignable-add' will take an optional '--name'
parameter, 'xl pci-assignable-remove' can be passed either a BDF or a name and
'xl pci-assignable-list' will take a optional '--show-names' flag which
determines whether names are displayed in its ou
From: Paul Durrant
There are only two call-sites. One always sets it to 0 (which is unnecessary
as the structure is already initialized to zero) and the other can simply set
the 'vdevfn' field directly (after proper structure initialization), avoiding
the need for a local variable.
A subsequent
From: Paul Durrant
This patch largely re-writes the code to parse a PCI_SPEC_STRING and enters
it via the newly introduced function. The new parser also deals with 'bdf'
and 'vslot' as non-positional paramaters, as per the documentation in
xl-pci-configuration(5).
The existing xlu_pci_parse_bdf(
From: Paul Durrant
... and modify libxl_pci_bdf_assignable_add/remove/list() to make use of it.
libxl_pci_bdf_assignable_add() will store the name of the device in xenstore
if the field is specified (i.e. non-NULL) and libxl_pci_bdf_assignable_remove()
will remove devices specified only by name,
From: Paul Durrant
A subsequent patch will introduce code to allow a name to be specified to
'xl pci-assignable-add' such that the assignable device may be referred to
by than name in subsequent operations.
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
---
Cc: Ian Jackson
---
docs/man/xl.1.p
From: Paul Durrant
These are re-worked versions of the remaining patches from v6 of the series
that were reverted by commit ac6a0af3870b "Revert patches that break libxl
API".
Paul Durrant (7):
docs/man: modify xl(1) in preparation for naming of assignable devices
libxlu: introduce xlu_pci_p
flight 158150 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 158164 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158134
test-armhf-a
On 23.12.2020 17:34, Andrew Cooper wrote:
> To inject a simulated resource failure, for testing purposes.
>
> Given a specific set of hypercall parameters, the failure is in a repeatable
> position, for the currently booted Xen. The exact position of failures is
> highly dependent on the build of
On 05/01/2021 16:06, Julien Grall wrote:
> (+ Ian and Andre)
>
> Hi Bertrand,
>
> On IRC, Ian pointed out that the smoke test was failing on Cubietruck.
> The only patches because the last success and the failure are your series.
>
> This seems to be a very early failure as there is no output fr
On 23.12.2020 17:34, Andrew Cooper wrote:
> RFC: Likely more to convert. This is just a minimal attempt.
Looks complete as far as this one file goes. More can be found
in evtchn_fifo.c of course.
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -16,6 +16,7 @@
>
> #in
(+ Ian and Andre)
Hi Bertrand,
On IRC, Ian pointed out that the smoke test was failing on Cubietruck.
The only patches because the last success and the failure are your series.
This seems to be a very early failure as there is no output from Xen [1].
I originally thought the problem was beca
On 23.12.2020 17:34, Andrew Cooper wrote:
> --- /dev/null
> +++ b/xen/common/dmalloc.c
> @@ -0,0 +1,19 @@
> +#include
> +#include
> +#include
> +
> +void dfree(struct domain *d, void *ptr)
> +{
> +atomic_dec(&d->dalloc_heap);
> +xfree(ptr);
> +}
> +
> +void *_dzalloc(struct domain *d, si
On 23.12.2020 17:34, Andrew Cooper wrote:
> RFC:
> * This probably wants to be less fatal in release builds
I'm not even convinced this wants to be a panic() in debug builds.
> * In an ideal world, we'd also want to count the total number of bytes
>allocated from the xmalloc heap, which wou
> -Original Message-
> From: Andrew Cooper
> Sent: Tuesday, January 5, 2021 6:05 AM
> To: Lengyel, Tamas ; xen-
> de...@lists.xenproject.org
> Cc: Tamas K Lengyel ; Jan Beulich
> ; George Dunlap ; Roger
> Pau Monné ; Wei Liu
> Subject: Re: [PATCH 1/2] x86/mem_sharing: copy cpuid during
Am Tue, 5 Jan 2021 16:37:44 +0100
schrieb Olaf Hering :
> -/*
> - * A precopy_policy callback may not be running in the same address
> - * space as libxc an so precopy_stats is passed by value.
> - */
> -typedef int (*precopy_policy_t)(struct precopy_stats, void *);
Does anyone happen what that
Move all save/restore related code from libxenguest.so into a separate
library. The only consumer is libxl-save-helper. There is no need to
have the moved code mapped all the time in binaries where libxenguest.so
is used.
Signed-off-by: Olaf Hering
---
The M2P defines are also moved with a separ
On Tue, 2021-01-05 at 09:45 -0500, boris.ostrov...@oracle.com wrote:
> For maintenance purposes. When something gets added in initialization
> path (prepare_boot_cpu() and such) we likely want to tear it down in
> cpu_die(). Today both native and Xen cpu_die() ops work the same but
> things change.
ACPI mandates use of E820 (or newer, e.g. EFI), and in fact firmware
has been observed to include E820_ACPI ranges in what E801 reports as
available (really "configured") memory. Since all 64-bit systems ought
to support ACPI, drop our use of older BIOS and boot loader interfaces.
Signed-off-by: J
Just code movement as a preparatory change before xg_sr_* will be moved.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_private.h | 10 ++
tools/libs/guest/xg_save_restore.h | 10 --
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/libs/guest/xg_pri
The last user was removed with commit b15bc4345e772df92e5ffdbc4c1e9ae2a6206617
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_save_restore.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/tools/libs/guest/xg_save_restore.h
b/tools/libs/guest/xg_save_restore.h
index e4fe747c4
Last user was removed with commit 4ddf474e2b7c045fadeaf765ac6157de745e84d6
Previously it was also used in migration code, which was removed with commit
b15bc4345e772df92e5ffdbc4c1e9ae2a6206617
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_domain.c | 2 +-
tools/libs/guest/xg_save_res
On 05.01.2021 14:56, Andrew Cooper wrote:
> On 05/01/2021 12:45, Jan Beulich wrote:
>> The increasing amount of constructs along the lines of
>>
>> if ( !condition )
>> {
>> ASSERT_UNREACHABLE();
>> return;
>> }
>>
>> is not only longer than necessary, but also doesn't p
On 1/4/21 8:41 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 18:44 -0500, boris.ostrov...@oracle.com wrote:
>> On 1/4/21 6:19 PM, David Woodhouse wrote:
>>> On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com
>>> wrote:
Why not xen_hvm_cpu_die too? common_cpu_die() sounds like
On 05.01.2021 14:38, Andrew Cooper wrote:
> On 05/01/2021 13:24, Jan Beulich wrote:
>> Even more so when using rcu_lock_domain_by_id() in place of the more
>> efficient rcu_lock_current_domain().
>>
>> Signed-off-by: Jan Beulich
>
> Acked-by: Andrew Cooper
Thanks.
>> ---
>> Besides get_pg_owne
On 05/01/2021 12:45, Jan Beulich wrote:
> The increasing amount of constructs along the lines of
>
> if ( !condition )
> {
> ASSERT_UNREACHABLE();
> return;
> }
>
> is not only longer than necessary, but also doesn't produce incident
> specific console output (except for
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年1月5日 19:17
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Penny Zheng
> ; Jiamei Xie ; nd
>
> Subject: Re: [PATCH 2/2] xen/arm: Add defensive barrier in get_cycles for
>
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年1月5日 19:01
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Penny Zheng
> ; Jiamei Xie ; nd
>
> Subject: Re: [PATCH] xen/arm: Using unsigned long for arm64 MPIDR mask
>
>
On 05/01/2021 13:24, Jan Beulich wrote:
> Even more so when using rcu_lock_domain_by_id() in place of the more
> efficient rcu_lock_current_domain().
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> Besides get_pg_owner(), gnttab_copy_lock_domain() has similar strange(?)
> behavio
On Tue, Jan 5, 2021 at 8:28 AM Jan Beulich wrote:
>
> For short-lived references rcu_lock_domain_by_id() is the better
> (slightly cheaper) alternative.
>
> Signed-off-by: Jan Beulich
Acked-by: Tamas K Lengyel
For short-lived references rcu_lock_domain_by_id() is the better
(slightly cheaper) alternative.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -537,7 +537,7 @@ static int audit(void)
p2m_type_t t;
mfn_t o_mfn;
-
For short-lived references rcu_lock_domain_by_id() is the better
(slightly cheaper) alternative.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mcheck/mcaction.c
@@ -87,7 +87,7 @@ mc_memerr_dhandler(struct mca_binfo *bin
BUG_ON( bank->mc_d
For short-lived references rcu_lock_domain_by_id() is the better
(slightly cheaper) alternative.
Signed-off-by: Jan Beulich
---
Is it really intentional for fill_ring_data() to return success (0) in
case the domain can't be found or has argo disabled? Even if so, the
uninitialized ent.max_message
For short-lived references rcu_lock_domain() is the better (slightly
cheaper) alternative.
Signed-off-by: Jan Beulich
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -642,7 +642,7 @@ int evtchn_close(struct domain *d1, int
*/
write_unlock(&chn1->lo
Even more so when using rcu_lock_domain_by_id() in place of the more
efficient rcu_lock_current_domain().
Signed-off-by: Jan Beulich
---
Besides get_pg_owner(), gnttab_copy_lock_domain() has similar strange(?)
behavior: They accept DOMID_SELF, but not the resolved ID of the caller.
---
v4: New.
In the course of preparing v4 of "evtchn: (not so) recent XSAs follow-on"
(which is a contextual prereq to some of the patches here) I've noticed
some slight inefficiencies. I've then also looked for similar patterns
elsewhere.
1: common: don't (kind of) open-code rcu_lock_domain_by_any_id()
2: ev
flight 158152 xen-unstable-smoke real [real]
flight 158156 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158152/
http://logs.test-lab.xenproject.org/osstest/logs/158156/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
The per-vCPU virq_lock, which is being held anyway, together with there
not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
is zero, provide sufficient guarantees. Undo the lock addition done for
XSA-343 (commit e045199c7c9c "evtchn: address races with
evtchn_reset()"). Update
First of all avoid "long" when "int" suffices, i.e. in particular when
merely conveying error codes. 32-bit values are slightly cheaper to
deal with on x86, and their processing is at least no more expensive on
Arm. Where possible use evtchn_port_t for port numbers and unsigned int
for other unsign
The local domain's lock is needed for the port freeing, but for the
remote side the per-channel lock is sufficient. Other logic then needs
rearranging, though, including the early dropping of both locks (and the
remote domain ref) in the ECS_PIRQ and ECS_VIRQ cases.
Note in particular that there i
On Tue, Jan 05, 2021 at 01:39:54PM +0100, Jan Beulich wrote:
> Both call sites clear the flag after a successfull call to
> update_entry(). This can be simplified by moving the clearing into the
> function, onto its success path.
>
> As a result of neither caller caring about update_entry()'s retu
The combination is pretty common, so adding a simple local helper seems
worthwhile. Make it const- and type-correct, in turn requiring the
two called function to also be const-correct (and at this occasion also
make them type-correct).
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/common/eve
port_is_valid() and evtchn_from_port() are fine to use without holding
any locks. Accordingly acquire the per-domain lock slightly later in
evtchn_close() and evtchn_bind_vcpu().
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -604,17
Global vIRQ-s have their event channel association tracked on vCPU 0.
Per-vCPU vIRQ-s can't have their notify_vcpu_id changed. Hence it is
well-known which vCPU's virq_to_evtchn[] needs updating.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/common/event_channel.c
+++ b/xen/common/event_chan
While there don't look to be any problems with this right now, the lock
order implications from holding the lock can be very difficult to follow
(and may be easy to violate unknowingly). The present callbacks don't
(and no such callback should) have any need for the lock to be held.
Signed-off-by:
Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
across pCPU-s) and the ones in EOI handling in PCI pass-through code,
serializing perhaps an entire domain isn't helpful when no state (which
isn't e.g. further protected by the per-channel lock) changes.
Unfortunately this i
The local domain's lock is needed for the port allocation, but for the
remote side the per-channel lock is sufficient. The per-channel locks
then need to be acquired slightly earlier, though.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.
Neither evtchn_status() nor domain_dump_evtchn_info() nor
flask_get_peer_sid() need to hold the per-domain lock - they all only
read a single channel's state (at a time, in the dump case).
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@
These are grouped into a series largely because of their origin,
not so much because there are heavy dependencies among them.
Compared to v3, there are several a new patches (in particular
the simultaneous locking of two domains' event locks gets done
away with) and movement of a controversial one
flight 158143 qemu-mainline real [real]
flight 158157 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158143/
http://logs.test-lab.xenproject.org/osstest/logs/158157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
The increasing amount of constructs along the lines of
if ( !condition )
{
ASSERT_UNREACHABLE();
return;
}
is not only longer than necessary, but also doesn't produce incident
specific console output (except for file name and line number). Allow
the intended effect to
On 10/12/2020 07:02, Penny Zheng wrote:
Hi Julien
Hi Penny,
Apologies for the late answer.
Thanks for the nice and detailed comments. (*^▽^*)
Here are the replies:
-Original Message-
From: Julien Grall
Sent: Tuesday, December 8, 2020 5:07 PM
To: Penny Zheng ; xen-devel@lists.x
Both call sites clear the flag after a successfull call to
update_entry(). This can be simplified by moving the clearing into the
function, onto its success path.
As a result of neither caller caring about update_entry()'s return value
anymore, the function gets switched to return void.
Signed-of
xen/mm.h has heavy dependencies, while in a number of cases only these
type definitions are needed. This separation then also allows pulling in
these definitions when including xen/mm.h would cause cyclic
dependencies.
Replace xen/mm.h inclusion where possible in include/xen/. (In
xen/iommu.h also
Doing so limits what can be done in (in particular included by) this per-
arch header. Abstract out page shift/size related #define-s, which is all
the respective headers care about. Extend the replacement / removal to
some x86 headers as well; some others now need to include page.h (and
they reall
While reviewing Hongyan's "x86/vmap: handle superpages in
vmap_to_mfn()" it became apparent that the interaction of
xen/mm.h and asm/page.h is problematic. Therefore some basic
page size related definitions get moved out of the latter, and
the mfn_t et al ones out of the former, each into new heade
On Mon, Dec 21, 2020 at 02:15:55PM +0100, Jan Beulich wrote:
> On 17.12.2020 12:57, Jan Beulich wrote:
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -76,20 +76,20 @@ static always_inline int xsm_default_act
> > case XSM_HOOK:
> > return 0;
> > case XS
On Tue, Dec 15, 2020 at 05:35:38PM +0100, Juergen Gross wrote:
> Today Xenstore is not restartable. This means a Xen server needing an
> update of xenstored has to be rebooted in order to let this update
> become effective.
>
> This patch series is changing that: The internal state of xenstored
>
On Wed, Dec 09, 2020 at 04:01:21PM +0100, Marek Marczykowski-Górecki wrote:
> On Sun, Nov 08, 2020 at 03:59:42PM +0100, Marek Marczykowski-Górecki wrote:
> > When device is removed, backend domain (which may be a driver domain) is
> > responsible for removing backend entries from xenstore. But in c
Am Wed, 23 Dec 2020 17:56:53 +0100
schrieb Maximilian Engelhardt :
> reproducible builds
Just wipe all built-in timestamps.
They serve no purpose.
Use git hashes to refer to specific build.
Olaf
pgpi9LRMqJGM9.pgp
Description: Digitale Signatur von OpenPGP
On Thu, Dec 24, 2020 at 08:02:37PM +0100, Hans van Kranenburg wrote:
> Hi,
>
> On 12/23/20 5:56 PM, Maximilian Engelhardt wrote:
> > check if a GNU date that supports the '-u -d @...' options and syntax or
> > a BSD date are available. If so, use the appropriate options for the
> > date command to
On Mon, Jan 04, 2021 at 12:52:23PM +0100, Olaf Hering wrote:
> Update to v1.21.1 to fix build in Tumbleweed, which has been broken
> since months due to lack of new release.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
> ---
> tools/firmware/etherboot/Makefile | 2 +-
> 1 file changed, 1
On Tue, Jan 05, 2021 at 11:54:11AM +, Wei Liu wrote:
> On Tue, Jan 05, 2021 at 09:30:48AM +0100, Olaf Hering wrote:
> > total_written tracks the number of transferred dirty pages.
> >
> > Signed-off-by: Olaf Hering
>
> Acked-by: Wei Liu
I've added libxenguest in the commit subject line to
1 - 100 of 115 matches
Mail list logo
