This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.
The first patch creates an empty
Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.
No functional improvements to x86 linker script.
Making use of common macros improves arm linker script with:
- explicit lis
Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.
Include this header in linker scripts for x86 and arm.
This patch serve
flight 169297 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169297/
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 Wed, Apr 06, 2022 at 09:00:01AM +0200, Jan Beulich wrote:
> On 06.04.2022 00:30, osstest service owner wrote:
> > flight 169172 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/169172/
> >
> > Failures :-/ but no regressions.
> > [...]
> > version targeted for testi
On Mon, Apr 04, 2022 at 12:04:03PM +0200, Roger Pau Monné wrote:
> Hello,
>
> We have the following boxes pending commission:
>
> italias
> * Commission flight at:
>http://logs.test-lab.xenproject.org/osstest/logs/169015/
> * Issues:
>All fine except for the leak-check errors:
> LE
> On 11 Apr 2022, at 07:15, Jan Beulich wrote:
>
> On 08.04.2022 22:25, Stefano Stabellini wrote:
>> On Fri, 8 Apr 2022, Jan Beulich wrote:
>>> On 08.04.2022 13:37, Luca Fancellu wrote:
> On 8 Apr 2022, at 10:01, Jan Beulich wrote:
>
> On 08.04.2022 10:45, Luca Fancel
> On 8 Apr 2022, at 13:10, Jan Beulich wrote:
>
> On 08.04.2022 13:15, Luca Fancellu wrote:
>>
>>
>>> On 8 Apr 2022, at 11:24, Jan Beulich wrote:
>>>
>>> On 08.04.2022 11:39, Luca Fancellu wrote:
> On 8 Apr 2022, at 10:10, Jan Beulich wrote:
>
> On 08.04.2022 10:45
flight 169299 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169299/
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 11.04.2022 10:54, Luca Fancellu wrote:
>> On 8 Apr 2022, at 13:10, Jan Beulich wrote:
>> On 08.04.2022 13:15, Luca Fancellu wrote:
On 8 Apr 2022, at 11:24, Jan Beulich wrote:
On 08.04.2022 11:39, Luca Fancellu wrote:
>> On 8 Apr 2022, at 10:10, Jan Beulich wrote:
>> On 08.04
Considering how long it took to get the XSA-400 series ready, it is
probably quite natural that in the course of doing so some further
items were found which want dealing with. There we go ...
1: IOMMU/x86: drop locking from quarantine_init() hooks
2: VT-d: drop ROOT_ENTRY_NR
3: VT-d: plug memory
Prior extension of these functions to enable per-device quarantine page
tables already didn't add more locking there, but merely left in place
what had been there before. But really locking is unnecessary here:
We're running with pcidevs_lock held (i.e. multiple invocations of the
same function [or
It's not only misplaced, but entirely unused.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -204,7 +204,6 @@ struct context_entry {
__uint128_t full;
};
};
-#define ROOT_ENTRY_NR (PAGE_SIZE_4K/sizeof(struct root_e
While 97af062b89d5 ("IOMMU/x86: maintain a per-device pseudo domain ID")
took care of not making things worse, plugging pre-existing leaks wasn't
the purpose of that change; they're not security relevant after all.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/dr
The field taking the value 7 (resulting in 18-bit DIDs when using the
calculation in cap_ndoms(), when the DID fields are only 16 bits wide)
is reserved. Instead of misbehaving in case we would encounter such an
IOMMU, refuse to use it.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vt
struct pci_dev has the wanted value directly available; use it. Note
that this fixes a - imo benign - mistake in reassign_device(): The unity
map removal ought to be based on the passed in devfn (as is the case on
the establishing side). This is benign because the mappings would be
removed anyway a
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
To handle phantom devices, several functions are passed separate "devfn"
arguments besides a PCI device. In such cases we want to log the phantom
device's coordinates instead of the main one's. (Note that not all of
the instances being changed are fallout from the referenced commit.)
Fixes: 1ee144
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
While it is okay for IOMMU page tables to be set up for guests starting
in PoD mode, actual device assignment may only occur once all PoD
entries have been removed from the P2M. So far this was enforced only
for boot-time assignment, and only in the tool stack.
Also use the new function to replace
On 06.04.2022 16:23, Jan Beulich wrote:
> On 05.04.2022 10:45, Roger Pau Monné wrote:
>> On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
>>> GrUB2 can be told to leave the screen in the graphics mode it has been
>>> using (or any other one), via "set gfxpayload=keep" (or suitable
>>> v
flight 169300 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169300/
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 11/04/2022 10:35, Jan Beulich wrote:
> Prior extension of these functions to enable per-device quarantine page
> tables already didn't add more locking there, but merely left in place
> what had been there before. But really locking is unnecessary here:
> We're running with pcidevs_lock held (i.
Hi Jan,
> >>> Signed-off-by: Jan Beulich
> >>
> >> Acked-by: Roger Pau Monné
> >
> > May I ask for an ack or otherwise for the changelog entry, please?
>
> Ping? This is the only thing missing for me to commit the remaining
> parts of this series.
Sorry for the late response, the previous e-ma
flight 169292 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 169273
Tests which are fa
On 11.04.2022 12:11, Henry Wang wrote:
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
>>>
>>> May I ask for an ack or otherwise for the changelog entry, please?
>>
>> Ping? This is the only thing missing for me to commit the remaining
>> parts of this series.
>
> Sorry for
Hi Michal,
On 11/04/2022 08:02, Michal Orzel wrote:
Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.
Include this hea
Hi Michal,
On 11/04/2022 08:03, Michal Orzel wrote:
Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.
No functional improvements to x86 linker script.
Making use of common
On 11.04.2022 12:01, Andrew Cooper wrote:
> On 11/04/2022 10:35, Jan Beulich wrote:
>> Prior extension of these functions to enable per-device quarantine page
>> tables already didn't add more locking there, but merely left in place
>> what had been there before. But really locking is unnecessary h
> On 11 Apr 2022, at 10:08, Jan Beulich wrote:
>
> On 11.04.2022 10:54, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 13:10, Jan Beulich wrote:
>>> On 08.04.2022 13:15, Luca Fancellu wrote:
> On 8 Apr 2022, at 11:24, Jan Beulich wrote:
> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>
Hi,
On 11/04/2022 07:26, Michal Orzel wrote:
On 08.04.2022 16:09, Peng Fan (OSS) wrote:
From: Peng Fan
The i.MX LPUART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
Chatper 13.6 Low Power Universal Asynchronous Receiver/
Transmitter (LPUART)
Tested-by: Henry Wang
Sign
On 11.04.2022 12:20, Luca Fancellu wrote:
>
>
>> On 11 Apr 2022, at 10:08, Jan Beulich wrote:
>>
>> On 11.04.2022 10:54, Luca Fancellu wrote:
On 8 Apr 2022, at 13:10, Jan Beulich wrote:
On 08.04.2022 13:15, Luca Fancellu wrote:
>> On 8 Apr 2022, at 11:24, Jan Beulich wrote:
>
Hi,
On 11/04/2022 07:24, Michal Orzel wrote:
On 08.04.2022 16:09, Peng Fan (OSS) wrote:
From: Peng Fan
Signed-off-by: Peng Fan
---
xen/arch/arm/Kconfig.debug | 14 +++
xen/arch/arm/arm64/debug-imx-lpuart.inc | 52 +
2 files changed, 66 insertions(
Hi,
On 11/04/2022 07:13, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
unsigned int port;
struct evtchn *chn;
+/*
+ * The work done below is an attempt to keep pIRQ-
On Mon, 2022-04-11 at 08:29 +, Luca Fancellu wrote:
> > On 11 Apr 2022, at 07:15, Jan Beulich wrote:
> > On 08.04.2022 22:25, Stefano Stabellini wrote:
> > > In my opinion it is best if the maintenance of boot_cpupools.c
> > > falls
> > > under "CPU POOLS". Luca, you can retain my reviewed-by
On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
> While it is okay for IOMMU page tables to be set up for guests starting
> in PoD mode, actual device assignment may only occur once all PoD
> entries have been removed from the P2M. So far this was enforced only
> for boot-time assignme
Hi Jan,
> -Original Message-
> From: Jan Beulich
> > Since you also mentioned the changelog entry, I will take a note of this
> > series and we can have a discussion about adding it when we do the
> > next Xen release (4.17). Would that sound ok with you?
>
> "Adding it" where? Maybe you
Hi Michal,
On 11/04/2022 08:02, Michal Orzel wrote:
This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defin
flight 169296 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
On 11.04.2022 12:29, Roger Pau Monné wrote:
> On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
>> While it is okay for IOMMU page tables to be set up for guests starting
>> in PoD mode, actual device assignment may only occur once all PoD
>> entries have been removed from the P2M. So fa
Hi Stefano,
> On 9 Apr 2022, at 02:44, Stefano Stabellini wrote:
>
> On Fri, 8 Apr 2022, Stefano Stabellini wrote:
>> On Wed, 23 Mar 2022, Rahul Singh wrote:
>>> in dom0less system. This patch introduce the new feature to support the
>>> signaling between two domUs in dom0less system.
>>>
>>> S
On 11.04.2022 12:25, Julien Grall wrote:
> On 11/04/2022 07:13, Jan Beulich wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
>> unsigned int port;
>> struct evtchn *chn
flight 169302 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169302/
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
Hi Luca,
On 08/04/2022 09:45, Luca Fancellu wrote:
diff --git a/docs/misc/arm/device-tree/cpupools.txt
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..40cc8135c66f
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,140 @@
+Boot time cpupools
Hi,
On 08/04/2022 16:26, Roger Pau Monné wrote:
On Fri, Apr 08, 2022 at 12:24:27PM +0100, Julien Grall wrote:
Hi Roger,
On 08/04/2022 12:16, Roger Pau Monné wrote:
On Fri, Apr 08, 2022 at 12:08:02PM +0100, Julien Grall wrote:
Hi,
On 08/04/2022 12:01, Roger Pau Monné wrote:
I could add a su
Hi,
On 11/04/2022 11:45, Jan Beulich wrote:
On 11.04.2022 12:25, Julien Grall wrote:
On 11/04/2022 07:13, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
unsigned int port;
stru
Hi Julien,
On 11.04.2022 12:20, Julien Grall wrote:
> Hi,
>
> On 11/04/2022 07:26, Michal Orzel wrote:
>> On 08.04.2022 16:09, Peng Fan (OSS) wrote:
>>> From: Peng Fan
>>>
>>> The i.MX LPUART Documentation:
>>> https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
>>> Chatper 13.6 Low Power Univ
https://doodle.com/meeting/participate/id/b822G1ge
I will probably leave the Doodle opened for few days (like up to Monday
evening) until we can decide the best schedule without waiting too long. When
I'll have the validated time slot, I'll communicate about it here.
So, as planned, here is
Hi Julien,
On 11.04.2022 12:23, Julien Grall wrote:
> Hi,
>
> On 11/04/2022 07:24, Michal Orzel wrote:
>> On 08.04.2022 16:09, Peng Fan (OSS) wrote:
>>> From: Peng Fan
>>>
>>> Signed-off-by: Peng Fan
>>> ---
>>> xen/arch/arm/Kconfig.debug | 14 +++
>>> xen/arch/arm/arm64/deb
> On 11 Apr 2022, at 11:58, Julien Grall wrote:
>
> Hi Luca,
>
> On 08/04/2022 09:45, Luca Fancellu wrote:
>> diff --git a/docs/misc/arm/device-tree/cpupools.txt
>> b/docs/misc/arm/device-tree/cpupools.txt
>> new file mode 100644
>> index ..40cc8135c66f
>> --- /dev/null
>> +++ b/d
flight 169294 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169294/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169286
test-armhf-armhf-libvirt 16 saver
flight 169305 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169305/
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
Hi Luca,
On 11/04/2022 12:30, Luca Fancellu wrote:
On 11 Apr 2022, at 11:58, Julien Grall wrote:
Hi Luca,
On 08/04/2022 09:45, Luca Fancellu wrote:
diff --git a/docs/misc/arm/device-tree/cpupools.txt
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..40cc8135c
On 11.04.2022 13:00, Julien Grall wrote:
> On 11/04/2022 11:45, Jan Beulich wrote:
>> On 11.04.2022 12:25, Julien Grall wrote:
>>> On 11/04/2022 07:13, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_
On 09/04/2022 06:50, Christoph Hellwig wrote:
> Just use a non-zero max_discard_sectors as an indicator for discard
> support, similar to what is done for write zeroes.
>
> The only places where needs special attention is the RAID5 driver,
> which must clear discard support for security reasons by
flight 169306 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169306/
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 169307 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169307/
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 169304 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169304/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index efb85c6d8e2d5..7e07dd69262a7 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1607,10 +1607,8 @@ static void nvme_config_discar
flight 169308 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169308/
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 Fri, 2022-04-08 at 11:20 +, Dario Faggioli wrote:
> On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote:
> >
> > Credit2 moving the vCPU-s off of their initially assigned ones
> > right
> > away of course renders sched_select_initial_cpu()'s use of
> > cpu_cycle()
> > pretty useless.
> >
Hello all,
EXECUTIVE SUMMARY
The current form of the Xen Summit this year we’re considering is as follows:
1. Two days of “primarily virtual” talks, with a physical add-on for those in
the Cambridge UK area, or willing to fly there. This would be relatively
low-key, probably hosted on a compa
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
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 v7:
- no changes
Changes in v6:
- add R-by
Changes in v5:
- no chang
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
---
Changes in v7:
- new patch
---
xen/common/sched/cpupool.c | 8 +++-
1 file changed
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
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
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_
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
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
Hi Stefano,
Thanks for reviewing the design.
> On 9 Apr 2022, at 2:00 am, Stefano Stabellini wrote:
>
> On Wed, 23 Mar 2022, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>>
>> Signed-off-by: Rah
flight 169310 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169310/
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 11.04.2022 17:20, Luca Fancellu wrote:
> 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
Hello David,
Thanks for reviewing the design and sorry for the late reply.
> On 24 Mar 2022, at 12:24 pm, David Vrabel wrote:
>
>
>
> On 23/03/2022 15:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less
Hi Ross,
Could you also ack this livpatch change?
Thanks.
On Tue, Mar 22, 2022 at 11:22:38AM +, Anthony PERARD wrote:
> This implement out-of-tree support, there's two ways to create an
> out-of-tree build tree (after that, `make` in that new directory
> works):
> make O=build
> mkdi
> From: Anthony PERARD
> Sent: Tuesday, March 22, 2022 11:22 AM
> To: xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Jan Beulich
> ; Daniel P . Smith ; Julien
> Grall ; Andrew Cooper ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini ; Wei Liu ; Roger Pau Monne
> ; Konrad Rzeszut
flight 169311 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169311/
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 Sat, Apr 09, 2022 at 06:50:24AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Johannes Thumshirn
Acked-by: David Sterba
On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote:
> Just use a non-zero max_discard_sectors as an indicator for discard
> support, similar to what is done for write zeroes.
>
> The only places where needs special attention is the RAID5 driver,
> which must clear discard support fo
On Sat, Apr 09, 2022 at 06:50:41AM +0200, Christoph Hellwig wrote:
> Abstract away implementation details from file systems by providing a
> block_device based helper to retrieve the discard granularity.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Martin K. Petersen
> Acked-by: Christoph
Hi Rahul,
Title: s/../.../
On 23/03/2022 15:43, Rahul Singh wrote:
in dom0less system. This patch introduce the new feature to support the
s/introduce/introduces/
s/the new/a/
signaling between two domUs in dom0less system.
Did you intend to add a newline before the second sentence?
Sig
Hi,
On 09/04/2022 02:00, Stefano Stabellini wrote:
On Wed, 23 Mar 2022, Rahul Singh wrote:
in dom0less system. This patch introduce the new feature to support the
signaling between two domUs in dom0less system.
Signed-off-by: Rahul Singh
---
docs/designs/dom0less-evtchn.md | 96
flight 169312 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169312/
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 169313 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169313/
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 169309 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169309/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169292
Tests which did not succeed
flight 169314 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169314/
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 169315 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169315/
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 169316 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169316/
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 169317 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169317/
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 169319 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169319/
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 169321 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169321/
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
Add variant of atomic/blocking_notifier_chain_register() functions that
doesn't allow to register notifier using a duplicated priority. The -EBUSY
error code is returned in this case by the new API functions.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 5 +++
kernel/notifier.c
Add blocking_notifier_call_chain_is_empty() that returns true if call
chain is empty.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 2 ++
kernel/notifier.c| 13 +
2 files changed, 15 insertions(+)
diff --git a/include/linux/notifier.h b/include/linux/notifie
SoC platforms often have multiple ways of how to perform system's
power-off and restart operations. Meanwhile today's kernel is limited to
a single option. Add combined power-off+restart handler call chain API,
which is inspired by the restart API. The new API provides both power-off
and restart fu
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Palmer Dabbelt
Signed-off-by: Dmitry Osipe
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Reviewed-by: Russell King (Oracle)
Signed-off-by: Dm
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Catalin Marinas
Signed-off-by: Dmitry Osip
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Michael Ellerman
Signed-off-by: Dmitry Osi
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/sh/kernel/r
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/x86/kernel/
1 - 100 of 115 matches
Mail list logo
