flight 167330 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167330/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167334 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167334/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Fri, Dec 03, 2021 at 01:38:48PM +0100, Jan Beulich wrote:
> On 02.12.2021 15:10, Roger Pau Monné wrote:
> > On Fri, Sep 24, 2021 at 11:47:41AM +0200, Jan Beulich wrote:
> >> @@ -689,7 +763,8 @@ int __init dom0_construct_pv(struct doma
> >> l1tab++;
> >>
> >> page =
Determining that behavior is correct (i.e. results in failure) for a
passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a bit
more obvious by checking input in generic code - both for singular
requests to not match the value and for range ones to not pass / wrap
through it.
For
This allows properly tying together INVALID_{G,M}FN and
INVALID_{G,M}FN_INITIALIZER as well as using the actual values in
compile time constant expressions (or even preprocessor dirctives).
Since INVALID_PFN is unused, and with x86'es paging_mark_pfn_dirty()
being the only user of pfn_t it also
Paul,
On 03.12.2021 12:18, Jan Beulich wrote:
> Two fixes and some tidying.
>
> 1: HVM: permit CLFLUSH{,OPT} on execute-only code segments
> 2: HVM: fail virt-to-linear conversion for insn fetches from non-code segments
> 3: emul: drop "seg" parameter from insn_fetch() hook
may I please ask for
flight 167325 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167325/
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
Hi Jan,
On 10/12/2021 09:44, Jan Beulich wrote:
On 03.12.2021 11:57, Jan Beulich wrote:
Instead of altering Arm's forward declarations, drop them. Like
elsewhere we should limit such to cases where the first use lives ahead
of the definition.
Signed-off-by: Jan Beulich
May I please ask for
Hi Oleksandr,
On 09/12/2021 20:50, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Remove the following sentence:
"This property is unnecessary when booting Dom0 using ACPI."
for "reg" and "interrupts" properties as the initialization is not
done via device-tree "hypervisor" node in
Hi Oleksandr,
On 09/12/2021 20:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen on Arm has gained new support recently to calculate and report
extended regions (unused address space) safe to use for external
mappings. These regions are reported via "reg" property under
From: Oleksandr Andrushchenko
While working with Xen's libxenvchan library I have faced an issue with
unmap notifications sent in wrong order if both UNMAP_NOTIFY_SEND_EVENT
and UNMAP_NOTIFY_CLEAR_BYTE were requested: first we send an event channel
notification and then clear the notification
On 03.12.2021 11:57, Jan Beulich wrote:
> Instead of altering Arm's forward declarations, drop them. Like
> elsewhere we should limit such to cases where the first use lives ahead
> of the definition.
>
> Signed-off-by: Jan Beulich
May I please ask for an Arm side ack (or otherwise) here?
Jan
flight 167335 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Fri, Dec 03, 2021 at 10:55:54AM +0100, Jan Beulich wrote:
> On 03.12.2021 10:49, Jan Beulich wrote:
> > On 03.12.2021 10:03, Roger Pau Monné wrote:
> >> On Fri, Sep 24, 2021 at 11:51:15AM +0200, Jan Beulich wrote:
> >>> This is to aid diagnosing issues and largely matches VT-d's behavior.
> >>>
flight 167317 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167317/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167287
test-armhf-armhf-libvirt 16
On 10.12.21 11:00, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 09/12/2021 20:50, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Remove the following sentence:
"This property is unnecessary when booting Dom0 using ACPI."
for "reg" and "interrupts" properties as the
On 30.11.2021 17:10, Jan Beulich wrote:
> ept_free_entry() gets called after a flush - if one is necessary in the
> first place - was already issued. That behavior is similar to NPT, which
> also doesn't have any further flush in p2m_free_entry(). (Furthermore,
> the function being recursive, in
On 10.12.21 11:09, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 09/12/2021 20:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen on Arm has gained new support recently to calculate and report
extended regions (unused address space) safe to use for external
mappings.
The original 1st patch has meanwhile gone in, but the adjustment requested
for patch 2 required a new prereq patch.
1: mm: introduce INVALID_{G,M}FN_RAW
2: memory: XENMEM_add_to_physmap (almost) wrapping checks
Jan
flight 167312 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167312/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate fail REGR. vs. 167241
Tests which did not
Hi, Jan!
On 10.12.21 11:39, Jan Beulich wrote:
> This allows properly tying together INVALID_{G,M}FN and
> INVALID_{G,M}FN_INITIALIZER as well as using the actual values in
> compile time constant expressions (or even preprocessor dirctives).
s/dirctives/directives
>
> Since INVALID_PFN is
> On 8 Dec 2021, at 18:10, Julien Grall wrote:
>
> Hi Luca,
>
> On 06/12/2021 15:36, Luca Fancellu wrote:
>> Currently the Xen UEFI stub can accept Xen boot arguments from
>> the Xen configuration file using the "options=" keyword, but also
>> directly from the device tree specifying
On Tue, Nov 30, 2021 at 05:10:53PM +0100, Jan Beulich wrote:
> ept_free_entry() gets called after a flush - if one is necessary in the
> first place - was already issued. That behavior is similar to NPT, which
> also doesn't have any further flush in p2m_free_entry(). (Furthermore,
> the function
On Fri, 10 Dec 2021 13:36:41 +0200, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Xen on Arm has gained new support recently to calculate and report
> extended regions (unused address space) safe to use for external
> mappings. These regions are reported via "reg" property under
>
10.12.2021 21:14, Rafael J. Wysocki пишет:
> On Fri, Nov 26, 2021 at 7:01 PM Dmitry Osipenko wrote:
>>
>> 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 ++
>>
On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>
> There is no need to annotate function prototypes with 'extern', it makes
> code less readable. Remove unnecessary annotations from .
>
> Signed-off-by: Dmitry Osipenko
I'm not sure that this is really useful.
Personally, I tend to
On Fri, Nov 26, 2021 at 7:01 PM Dmitry Osipenko wrote:
>
> 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| 14 ++
> 2 files changed, 16
flight 167349 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167349/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
10.12.2021 21:35, Rafael J. Wysocki пишет:
> On Fri, Dec 10, 2021 at 7:16 PM Dmitry Osipenko wrote:
>>
>> 10.12.2021 21:09, Rafael J. Wysocki пишет:
>>> On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
There is no need to annotate function prototypes with 'extern', it makes
flight 167350 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167350/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
Hi Oleksandr,
On 25/11/2021 11:02, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
vpci_process_pending is defined with different attributes, e.g.
with __must_check if CONFIG_HAS_VPCI enabled and not otherwise.
Fix this by defining both of the definitions with __must_check.
On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko wrote:
>
> 29.11.2021 03:26, Michał Mirosław пишет:
> > On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
> >> 28.11.2021 03:28, Michał Mirosław пишет:
> >>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
> Add
On Fri, Dec 10, 2021 at 7:16 PM Dmitry Osipenko wrote:
>
> 10.12.2021 21:09, Rafael J. Wysocki пишет:
> > On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
> >>
> >> There is no need to annotate function prototypes with 'extern', it makes
> >> code less readable. Remove unnecessary
10.12.2021 22:05, Rafael J. Wysocki пишет:
> On Fri, Dec 10, 2021 at 7:52 PM Dmitry Osipenko wrote:
>>
>> 10.12.2021 21:19, Rafael J. Wysocki пишет:
>> ...
+bool atomic_notifier_has_unique_priority(struct atomic_notifier_head *nh,
+ struct notifier_block *n)
+{
+
On 06/12/2021 10:49, Jan Beulich wrote:
> On 26.11.2021 13:34, Andrew Cooper wrote:
>> --- a/xen/arch/x86/acpi/wakeup_prot.S
>> +++ b/xen/arch/x86/acpi/wakeup_prot.S
>> @@ -63,7 +63,24 @@ ENTRY(s3_resume)
>> pushq %rax
>> lretq
>> 1:
>> -#ifdef CONFIG_XEN_SHSTK
>> +#if
flight 167347 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167347/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>
> Add atomic/blocking_notifier_has_unique_priority() helpers which return
> true if given handler has unique priority.
>
> Signed-off-by: Dmitry Osipenko
> ---
> include/linux/notifier.h | 5 +++
> kernel/notifier.c| 69
Hi, Julien!
On 10.12.21 19:52, Julien Grall wrote:
> Hi Oleksandr,
>
> On 09/12/2021 07:29, Oleksandr Andrushchenko wrote:
>> +unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
>> +{
>> + if ( !has_vpci(d) )
>> + return 0;
>> +
>> + if ( is_hardware_domain(d) )
>> +
10.12.2021 21:19, Rafael J. Wysocki пишет:
...
>> +bool atomic_notifier_has_unique_priority(struct atomic_notifier_head *nh,
>> + struct notifier_block *n)
>> +{
>> + unsigned long flags;
>> + bool ret;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> + ret =
On Fri, Dec 10, 2021 at 8:04 PM Dmitry Osipenko wrote:
>
> 10.12.2021 21:27, Rafael J. Wysocki пишет:
> > On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko wrote:
> >>
> >> 29.11.2021 03:26, Michał Mirosław пишет:
> >>> On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
>
commit f37f29d31488 "xen: slightly simplify bufioreq handling" hard
coded setting req.count = 1 during initial field setup before the main
loop. This missed a subtlety that an early exit from the loop when
there are no ioreqs to process, would have req.count == 0 for the return
value.
10.12.2021 22:14, Rafael J. Wysocki пишет:
> On Fri, Dec 10, 2021 at 8:04 PM Dmitry Osipenko wrote:
>>
>> 10.12.2021 21:27, Rafael J. Wysocki пишет:
>>> On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko wrote:
29.11.2021 03:26, Michał Mirosław пишет:
> On Mon, Nov 29, 2021 at
flight 167344 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
Hi Luca,
On 10/12/2021 10:26, Luca Fancellu wrote:
On 8 Dec 2021, at 18:10, Julien Grall wrote:
Hi Luca,
On 06/12/2021 15:36, Luca Fancellu wrote:
Currently the Xen UEFI stub can accept Xen boot arguments from
the Xen configuration file using the "options=" keyword, but also
directly
On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>
> Emit warning if unregister_restart_handler() fails since it never should
> fail. This will ease further API development by catching mistakes early.
>
> Signed-off-by: Dmitry Osipenko
> ---
> kernel/reboot.c | 2 +-
> 1 file changed, 1
On 10.12.2021 15:00, Bertrand Marquis wrote:
>> On 10 Dec 2021, at 13:54, Jan Beulich wrote:
>> On 10.12.2021 14:50, Bertrand Marquis wrote:
On 10 Dec 2021, at 13:11, Jan Beulich wrote:
do_memory_op() supplies return value and has "errno" set the usual way.
Don't overwrite
flight 167336 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167336/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail blocked in 167312
10.12.2021 21:09, Rafael J. Wysocki пишет:
> On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>>
>> There is no need to annotate function prototypes with 'extern', it makes
>> code less readable. Remove unnecessary annotations from .
>>
>> Signed-off-by: Dmitry Osipenko
>
> I'm not sure
10.12.2021 22:08, Rafael J. Wysocki пишет:
> On Fri, Dec 10, 2021 at 7:54 PM Dmitry Osipenko wrote:
>>
>> 10.12.2021 21:32, Rafael J. Wysocki пишет:
>>> On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
Emit warning if unregister_restart_handler() fails since it never should
flight 167345 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167346 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167346/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Fri, Dec 10, 2021 at 7:52 PM Dmitry Osipenko wrote:
>
> 10.12.2021 21:19, Rafael J. Wysocki пишет:
> ...
> >> +bool atomic_notifier_has_unique_priority(struct atomic_notifier_head *nh,
> >> + struct notifier_block *n)
> >> +{
> >> + unsigned long flags;
> >> + bool
10.12.2021 22:44, Dmitry Osipenko пишет:
> 10.12.2021 22:42, Dmitry Osipenko пишет:
> ...
There is no strong requirement for priorities to be unique, the reboot.c
code will work properly.
>>>
>>> In which case adding the WARN() is not appropriate IMV.
>>>
>>> Also I've looked at the
flight 167356 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167356/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167358 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167358/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167360 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167360/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On 10.12.2021 17:19, Andrew Cooper wrote:
> On 06/12/2021 10:49, Jan Beulich wrote:
>> On 26.11.2021 13:34, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/acpi/wakeup_prot.S
>>> +++ b/xen/arch/x86/acpi/wakeup_prot.S
>>> @@ -63,7 +63,24 @@ ENTRY(s3_resume)
>>> pushq %rax
>>> lretq
On 06/12/2021 11:06, Jan Beulich wrote:
> On 26.11.2021 17:38, Andrew Cooper wrote:
>> --- a/xen/arch/x86/efi/stub.c
>> +++ b/xen/arch/x86/efi/stub.c
>> @@ -11,6 +11,8 @@
>> #include
>> #include
>>
>> +bool __initdata efi_no_cet_ibt;
> I'm having trouble seeing what this is needed for - when
Hi Oleksandr,
On 09/12/2021 07:29, Oleksandr Andrushchenko wrote:
+unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
+{
+if ( !has_vpci(d) )
+return 0;
+
+if ( is_hardware_domain(d) )
+{
+int ret = pci_host_iterate_bridges_and_count(d,
10.12.2021 21:32, Rafael J. Wysocki пишет:
> On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>>
>> Emit warning if unregister_restart_handler() fails since it never should
>> fail. This will ease further API development by catching mistakes early.
>>
>> Signed-off-by: Dmitry Osipenko
>>
10.12.2021 21:27, Rafael J. Wysocki пишет:
> On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko wrote:
>>
>> 29.11.2021 03:26, Michał Mirosław пишет:
>>> On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
28.11.2021 03:28, Michał Mirosław пишет:
> On Fri, Nov 26, 2021 at
10.12.2021 22:33, Dmitry Osipenko пишет:
>> Not really, they only prevent the race from occurring while
>> notifier_has_unique_priority() is running.
>>
>> If anyone depends on this check for correctness, they need to lock the
>> rwsem, do the check, do the thing depending on the check while
flight 167348 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167348/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 167336
flight 167363 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167363/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167355 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167355/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167351 linux-linus real [real]
flight 167359 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167351/
http://logs.test-lab.xenproject.org/osstest/logs/167359/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
From: Thomas Gleixner
Add new allocation functions which can be activated by domain info
flags. They store the groups pointer in struct msi_device_data.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
include/linux/msi.h |4
From: Thomas Gleixner
Allocate the MSI device data on first invocation of the allocation function.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Nishanth Menon
Cc: Tero Kristo
Cc: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org
From: Thomas Gleixner
No more users. Refactor the core code accordingly and move the global
interface under CONFIG_PCI_MSI_ARCH_FALLBACKS.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
include/linux/msi.h | 29 +++-
flight 167352 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167352/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
From: Thomas Gleixner
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/base/platform-msi.c | 10 +-
drivers/dma/qcom/hidma.c
From: Thomas Gleixner
Provide a domain info flag which makes the core code check for a contiguous
MSI-X index on allocation. That's simpler than checking it at some other
domain callback in architecture code.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason
From: Thomas Gleixner
Just use the core function msi_get_virq().
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Peter Ujfalusi
Cc: Vinod Koul
Cc: dmaeng...@vger.kernel.org
---
drivers/dma/ti/k3-udma-private.c |6 ++
From: Thomas Gleixner
Storing the platform private data in a MSI descriptor is sloppy at
best. The data belongs to the device and not to the descriptor.
Add a pointer to struct msi_device_data and store the pointer there.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
From: Thomas Gleixner
Let the core code fiddle with the MSI descriptor retrieval.
Signed-off-by: Thomas Gleixner
Tested-by: Robin Murphy
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Will Deacon
Cc: Joerg Roedel
Cc: linux-arm-ker...@lists.infradead.org
Cc:
From: Thomas Gleixner
All non PCI/MSI usage variants have data structures in struct msi_desc with
only one member: xxx_index. PCI/MSI has a entry_nr member.
Add a common msi_index member to struct msi_desc so all implementations can
share it which allows further consolidation.
Signed-off-by:
On 12/10/21 4:28 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
While working with Xen's libxenvchan library I have faced an issue with
unmap notifications sent in wrong order if both UNMAP_NOTIFY_SEND_EVENT
and UNMAP_NOTIFY_CLEAR_BYTE were requested: first we send an event
flight 167354 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167354/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
From: Thomas Gleixner
The only unconditional part of MSI data in struct device is the irqdomain
pointer. Everything else can be allocated on demand. Create a data
structure and move the irqdomain pointer into it. The other MSI specific
parts are going to be removed from struct device in later
From: Thomas Gleixner
Allocate MSI device data on first use, i.e. when a PCI driver invokes one
of the PCI/MSI enablement functions.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
---
drivers/pci/msi/msi.c | 20
From: Thomas Gleixner
Create struct msi_device_data and add a pointer of that type to struct
dev_msi_info, which is part of struct device. Provide an allocator function
which can be invoked from the MSI interrupt allocation code pathes.
Add a properties field to the data structure as a first
From: Thomas Gleixner
to determine whether this is MSI or MSIX instead of consulting MSI
descriptors.
Signed-off-by: Thomas Gleixner
---
V2: Use PCI device property - Jason
---
kernel/irq/msi.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
--- a/kernel/irq/msi.c
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
---
V3: Use pci_dev->msix_enabled.
---
arch/x86/pci/xen.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
---
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
---
V3: Use pci_dev->msix_enabled - Jason
---
arch/x86/kernel/apic/msi.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/arch/x86/kernel/apic/msi.c
+++
There are quite some places which retrieve the first MSI descriptor to
evaluate whether the setup is for MSI or MSI-X. That's required because
pci_dev::msi[x]_enabled is only set when the setup completed successfully.
There is no real reason why msi[x]_enabled can't be set at the beginning of
the
This is the second part of [PCI]MSI refactoring which aims to provide the
ability of expanding MSI-X vectors after enabling MSI-X.
This is based on the first part of this work which can be found here:
https://lore.kernel.org/r/20211206210147.872865...@linutronix.de
and has been applied to:
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
---
V3: Use pci_dev->msix_enabled - Jason
---
arch/powerpc/platforms/pseries/msi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Thomas Gleixner
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
Cc: Arnd Bergmann
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: linuxppc-...@lists.ozlabs.org
---
V3: Use pci_dev property - Jason
V2: Invoke the function with the correct number of
From: Thomas Gleixner
Allocate the MSI device data on first invocation of the allocation function
for platform MSI private data.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/base/platform-msi.c |8 +++-
1 file changed, 7
From: Thomas Gleixner
Allocate the MSI device data on first invocation of the allocation function.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Stuart Yoder
Cc: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-msi.c | 14 --
1
From: Thomas Gleixner
Storing a pointer to the MSI descriptor just to keep track of the Linux
interrupt number is daft. Use msi_get_virq() instead.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Vinod Koul
Cc: dmaeng...@vger.kernel.org
---
From: Thomas Gleixner
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Nishanth Menon
Cc: Tero Kristo
Cc: Santosh Shilimkar
Cc: Thomas Gleixner
Cc:
From: Thomas Gleixner
Replace open coded MSI descriptor chasing and use the proper accessor
functions instead.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/msi.c | 26 ++
1 file changed, 10
From: Thomas Gleixner
Storing a pointer to the MSI descriptor just to track the Linux interrupt
number is daft. Just store the interrupt number and be done with it.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Stuart Yoder
Cc: Laurentiu
From: Thomas Gleixner
Use msi_get_vector() and handle the return value to be compatible.
No functional change intended.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
---
V2: Handle the INTx case directly instead of trying to be overly smart - Marc
---
drivers/pci/msi/msi.c
From: Thomas Gleixner
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Stuart Yoder
Cc: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-allocator.c |2 +-
From: Thomas Gleixner
Set the domain info flag and remove the check.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: "Cédric Le Goater"
Cc: linuxppc-...@lists.ozlabs.org
---
V2: Remove it completely - Cedric
---
From: Thomas Gleixner
It's hard to distinguish what platform_msi_domain_alloc() and
platform_msi_domain_alloc_irqs() are about. Make the distinction more
explicit and add comments which explain the use cases properly.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by:
From: Thomas Gleixner
Let the core code fiddle with the MSI descriptor retrieval.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Cc: Mark Rutland
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/perf/arm_smmuv3_pmu.c |5
From: Thomas Gleixner
The usage of msi_desc::pci::entry_nr is confusing at best. It's the index
into the MSI[X] descriptor table.
Use msi_desc::msi_index which is shared between all MSI incarnations
instead of having a PCI specific storage for no value.
Signed-off-by: Thomas Gleixner
1 - 100 of 140 matches
Mail list logo
