For support of long running hypercalls xen_maybe_preempt_hcall() is
calling cond_resched() in case a hypercall marked as preemptible has
been interrupted.
Normally this is no problem, as only hypercalls done via some ioctl()s
are marked to be preemptible. In rare cases when during such a
preemptib
Hi,
On 8/20/20 2:56 AM, Sasha Levin wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
> frontend").
>
> The bot has tested the following trees: v5.8.1, v5
On 20.08.2020 00:50, Roman Shaposhnik wrote:
> below you can see a trace of Xen 4.14.0 failing on Dell IoT Gateway 3001
> without efi=no-rs. Please let me know if I can provide any additional
> information.
One of the usual firmware issues:
> Xen 4.14.0
> (XEN) Xen version 4.14.0 (@) (gcc (Alpine
On 19/08/2020 10:22, Jan Beulich wrote:
On 17.08.2020 15:03, Julien Grall wrote:
On 17/08/2020 12:50, Roger Pau Monné wrote:
On Mon, Aug 17, 2020 at 12:05:54PM +0100, Julien Grall wrote:
The only way I could see to make it work would be to use the same trick as
we do for {read, write}_atomi
On 20.08.2020 11:14, Julien Grall wrote:
>
>
> On 19/08/2020 10:22, Jan Beulich wrote:
>> On 17.08.2020 15:03, Julien Grall wrote:
>>> On 17/08/2020 12:50, Roger Pau Monné wrote:
On Mon, Aug 17, 2020 at 12:05:54PM +0100, Julien Grall wrote:
> The only way I could see to make it work woul
Hi,
On 18/08/2020 14:47, Bertrand Marquis wrote:
This patch serie is adding Neoverse N1 processor identification and
enabling the processor errata 1165522 for Neoverse N1 processors.
Bertrand Marquis (2):
arm: Add Neoverse N1 processor identifation
xen/arm: Enable CPU Errata 1165522 for N
On Thu, Aug 20, 2020 at 11:30:25AM +0200, Roger Pau Monné wrote:
> Right, so you only need access to the ESRT table, that's all. Then I
> think we need to make sure Xen doesn't use this memory for anything
> else, which will require some changes in Xen (or at least some
> checks?).
>
> We also nee
On 20/08/2020 10:25, Jan Beulich wrote:
On 20.08.2020 11:14, Julien Grall wrote:
On 19/08/2020 10:22, Jan Beulich wrote:
On 17.08.2020 15:03, Julien Grall wrote:
On 17/08/2020 12:50, Roger Pau Monné wrote:
On Mon, Aug 17, 2020 at 12:05:54PM +0100, Julien Grall wrote:
The only way I coul
On Thu, 20 Aug 2020 at 11:30, Roger Pau Monné wrote:
>
> On Wed, Aug 19, 2020 at 01:33:39PM +0200, Norbert Kaminski wrote:
> >
> > On 19.08.2020 10:19, Roger Pau Monné wrote:
> > > On Tue, Aug 18, 2020 at 08:40:18PM +0200, Marek Marczykowski-Górecki
> > > wrote:
> > > > On Tue, Aug 18, 2020 at 07
Hi Roger,
On 18/08/2020 09:35, Roger Pau Monné wrote:
On Mon, Aug 17, 2020 at 06:56:24PM +0100, Julien Grall wrote:
On 17/08/2020 18:33, Roger Pau Monné wrote:
On Mon, Aug 17, 2020 at 04:53:51PM +0100, Julien Grall wrote:
On 17/08/2020 16:03, Roger Pau Monné wrote:
On Mon, Aug 17, 2020 a
Hi,
Sorry for the late answer.
On 14/08/2020 10:25, Bertrand Marquis wrote:
On 1 Aug 2020, at 00:03, Stefano Stabellini wrote:
On Fri, 31 Jul 2020, Bertrand Marquis wrote:
On 31 Jul 2020, at 12:18, Jan Beulich wrote:
On 31.07.2020 12:12, Julien Grall wrote:
On 31/07/2020 07:39, Jan Beu
This patch series fixes issues around the vif-nat script when
setting up the vif interface and dhcp server in dom0.
It has been validated and used in Yocto and meta-arm-autonomy
Diego Sueiro (3):
tools/hotplug: Fix hostname setting in vif-nat
tools/hotplug: Fix dhcpd symlink removal in vif-na
Hi Roman,
On 16/08/2020 21:45, Roman Shaposhnik wrote:
On Sun, Aug 16, 2020 at 7:54 AM Julien Grall wrote:
On 15/08/2020 21:43, Roman Shaposhnik wrote:
Hi!
Hi,
with the recent excellent work by Anastasiia committed to the u-boot's
main line, we now have two different ways of bringing ARM
Setting the hostname is failing because the "$XENBUS_PATH/domain"
doesn't exist anymore. To fix this we set it to dom$domid
Signed-off-by: Diego Sueiro
---
tools/hotplug/Linux/vif-nat | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/Linux/vif-nat b/tools/hotplug/
On 20/08/2020 05:45, Jedi Chen wrote:
Hi xen-devel,
Hi,
I am very interesting about the VIRTIO on Xen. And from one meeting
report of AGL Virtualization Expert Group (EG-VIRT)
https://wiki.automotivelinux.org/eg-virt-meetings#pm_cest_meeting4, I
got the information that ARM and Linaro a
Copy temp files used to add/remove dhcpd configurations to avoid
replacing potential symlinks.
Signed-off-by: Diego Sueiro
---
tools/hotplug/Linux/vif-nat | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/hotplug/Linux/vif-nat b/tools/hotplug/Linux/vif-nat
in
Newer versions of the ISC dhcp server expect the dhcpd.conf file
to be located at /etc/dhcp directory.
Also, some distributions and Yocto based ones have these installation
paths by default: /etc/init.d/{isc-dhcp-server,dhcp-server} and
/etc/default/dhcp-server.
Signed-off-by: Diego Sueiro
---
On Thu, 20 Aug 2020 at 11:59, Julien Grall wrote:
>
>
>
> On 20/08/2020 05:45, Jedi Chen wrote:
> > Hi xen-devel,
>
> Hi,
>
> >
> > I am very interesting about the VIRTIO on Xen. And from one meeting
> > report of AGL Virtualization Expert Group (EG-VIRT)
> > https://wiki.automotivelinux.org/eg-vi
On 19/08/2020 12:04, Simon Leiner wrote:
Hi everyone,
Hi Simon,
I'm working on a virtio driver for the Linux kernel that supports the
dynamic connection of devices via the Xenbus (as part of a research
project at the Karlsruhe Institute of Technology).
There is a lot of interest to get
On Thu, Aug 20, 2020 at 9:35 AM Jan Beulich wrote:
>
> As far as making cases like this work by default, I'm afraid it'll
> need to be proposed to replace me as the maintainer of EFI code in
> Xen. I will remain on the position that it is not acceptable to
> apply workarounds for firmware issues
On 8/20/20 1:50 PM, Julien Grall wrote:
> Hi Roman,
>
> On 16/08/2020 21:45, Roman Shaposhnik wrote:
>> On Sun, Aug 16, 2020 at 7:54 AM Julien Grall wrote:
>>> On 15/08/2020 21:43, Roman Shaposhnik wrote:
Hi!
>>>
>>> Hi,
>>>
with the recent excellent work by Anastasiia committed to the
Hi Julien,
On 20.08.20 13:17, Julien Grall wrote:
> There is a lot of interest to get Virtio working on Xen at the moment.
> Is this going to be a new transport layer for Virtio?
It is designed that way, yes. The current implementation (based on
virtio_mmio.c) has a few limitations:
- Only the
flight 152632 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152632/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Aug 20, 2020, at 07:24, George Dunlap wrote:
>
>> On Thu, Aug 20, 2020 at 9:35 AM Jan Beulich wrote:
>
>>
>> As far as making cases like this work by default, I'm afraid it'll
>> need to be proposed to replace me as the maintainer of EFI code in
>> Xen. I will remain on the position that i
Thank you very much! It’s very valuable information.
Regards,
> 在 2020年8月20日，19:02，Julien Grall 写道：
>
> On Thu, 20 Aug 2020 at 11:59, Julien Grall wrote:
>>
>>
>>
>>> On 20/08/2020 05:45, Jedi Chen wrote:
>>> Hi xen-devel,
>>
>> Hi,
>>
>>>
>>> I am very interesting about the VIRTIO on X
On Wed, Aug 19, 2020 at 01:33:39PM +0200, Norbert Kaminski wrote:
>
> On 19.08.2020 10:19, Roger Pau Monné wrote:
> > On Tue, Aug 18, 2020 at 08:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Tue, Aug 18, 2020 at 07:21:14PM +0200, Roger Pau Monné wrote:
> > > > > Let me draw the picture
On Thu, Aug 20, 2020 at 11:34:54AM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Aug 20, 2020 at 11:30:25AM +0200, Roger Pau Monné wrote:
> > Right, so you only need access to the ESRT table, that's all. Then I
> > think we need to make sure Xen doesn't use this memory for anything
> > else, w
On Wed, Aug 19, 2020 at 08:09:11PM -0700, Randy Dunlap wrote:
> Hi Konrad,
Hey Randy,
I believe Juergen is picking this up.
>
> ping.
>
> I am still seeing this build error. It looks like this is
> in your territory to merge...
>
>
> On 8/13/20 4:00 PM, Randy Dunlap wrote:
> > From: Randy Dun
On 20.08.20 16:40, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 19, 2020 at 08:09:11PM -0700, Randy Dunlap wrote:
Hi Konrad,
Hey Randy,
I believe Juergen is picking this up.
Yes, have queued it for rc2.
Juergen
ping.
I am still seeing this build error. It looks like this is
in your territ
On Tue, Aug 11, 2020 at 11:07:36PM +0200, David Hildenbrand wrote:
> On 11.08.20 11:44, Roger Pau Monne wrote:
> > This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> > being used by non DAX devices.
> >
> > No functional change intended.
> >
> > Signed-off-by: Roger Pau Monné
On 19/08/2020 23:50, Roman Shaposhnik wrote:
> Hi!
>
> below you can see a trace of Xen 4.14.0 failing on Dell IoT Gateway 3001
> without efi=no-rs. Please let me know if I can provide any additional
> information.
Just to be able to get all datapoints, could you build Xen with
CONFIG_EFI_SET_VIR
flight 152628 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152628/
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-i386-libvirt
flight 152623 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152623/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 152597
test-am
Hello all.
I would like to clarify some questions based on the comments for the
patch series. I put them together (please see below).
On 06.08.20 14:29, Jan Beulich wrote:
On 06.08.2020 13:08, Julien Grall wrote:
On 05/08/2020 20:30, Oleksandr wrote:
I was thinking how to split handle_h
flight 152627 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152627/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5a6d764e1d073d28e8f398289ccb5592bf9a72ba
baseline version:
ovmf a048af3c9073e4b8108e6
On Thu, 20 Aug 2020, Julien Grall wrote:
> > Part of virtio is having shared memory. So naturally, I'm using Xen's
> > grant system for that. Part of the Xenbus client API is the function
> > xenbus_grant_ring which, by its documentation grants access to a block
> > of memory starting at vaddr to a
On Thu, Aug 20, 2020 at 4:27 AM Oleksandr Andrushchenko
wrote:
>
>
> On 8/20/20 1:50 PM, Julien Grall wrote:
> > Hi Roman,
> >
> > On 16/08/2020 21:45, Roman Shaposhnik wrote:
> >> On Sun, Aug 16, 2020 at 7:54 AM Julien Grall wrote:
> >>> On 15/08/2020 21:43, Roman Shaposhnik wrote:
> Hi!
>
On Tue, 18 Aug 2020, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH 00/14] kernel-doc: public/arch-arm.h"):
> > I am replying to this email as I have been told that the original was
> > filtered as spam due to the tarball attachment. The tarball contains
> > some example html output do
On Tue, 18 Aug 2020, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH 01/14] kernel-doc: public/arch-arm.h"):
> > From: Stefano Stabellini
> >
> > Convert in-code comments to kernel-doc format wherever possible.
>
> Thanks. But, err, I think there is not yet any in-tree machinery for
> a
We already have special casing to handle reads of this MSR for revF
chips, so do as the comment in svm_msr_read_intercept says and drop
writes. This is in preparation for changing the default MSR write
behavior, which will instead return #GP on not explicitly handled
writes.
Signed-off-by: Roger P
Hello,
The current series attempts to change the current MSR default handling
behavior, which is to silently drop writes to writable MSRs, and allow
reading any MSR not explicitly handled.
After this series access to MSRs not explicitly handled will trigger a
#GP fault. I've tested this series wi
The SYSCFG, TOP_MEM1 and TOP_MEM2 MSRs are currently exposed to guests
and writes are silently discarded. Make this explicit in the SVM code
now, and just return default constant values when attempting to read
any of the MSRs, while continuing to silently drop writes.
Signed-off-by: Roger Pau Monn
Such handling consist in checking that no bits have been changed from
the read value, if that's the case silently drop the write, otherwise
inject a fault.
At least Windows guests will expect to write to the MISC_ENABLE MSR
with the same value that's been read from it.
Signed-off-by: Roger Pau Mo
Change the catch-all behavior for MSR not explicitly handled. Instead
of allow full read-access to the MSR space and silently dropping
writes return an exception when the MSR is not explicitly handled.
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
xen/arch/x86/pv/emul-priv-op.c | 1
Linux PV guests will attempt to read the FEATURE_CONTROL MSR, so move
the handling done in VMX code into guest_rdmsr as it can be shared
between PV and HVM guests that way.
Signed-off-by: Roger Pau Monné
---
Changes from v1:
- Move the VMX implementation into guest_rdmsr.
---
xen/arch/x86/hvm/v
From: Andrew Cooper
Now that the main PV/HVM MSR handlers raise #GP for all unknown MSRs, there is
no need to special case these MSRs any more.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x86/msr.c | 46 -
Report the hardware value of DE_CFG on AMD hardware and silently drop
writes.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x86/msr.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/x86/msr.c b/x
From: Andrew Cooper
Change the catch-all behavior for MSR not explicitly handled. Instead
of allow full read-access to the MSR space and silently dropping
writes return an exception when the MSR is not explicitly handled.
Signed-off-by: Andrew Cooper
[remove rdmsr_safe from default case in svm_
On Thu, Aug 20, 2020 at 5:56 AM Andrew Cooper wrote:
>
> On 19/08/2020 23:50, Roman Shaposhnik wrote:
> > Hi!
> >
> > below you can see a trace of Xen 4.14.0 failing on Dell IoT Gateway 3001
> > without efi=no-rs. Please let me know if I can provide any additional
> > information.
>
> Just to be
On 12.08.20 11:19, Julien Grall wrote:
Hi,
Hi Julien, Stefano
On 11/08/2020 23:48, Stefano Stabellini wrote:
I have the impression that we disagree in what the Device Emulator
is meant to
do. IHMO, the goal of the device emulator is to emulate a device in an
arch-agnostic way.
That wo
On Thu, Aug 20, 2020 at 1:34 AM Jan Beulich wrote:
>
> On 20.08.2020 00:50, Roman Shaposhnik wrote:
> > below you can see a trace of Xen 4.14.0 failing on Dell IoT Gateway 3001
> > without efi=no-rs. Please let me know if I can provide any additional
> > information.
>
> One of the usual firmware
Hello,
This series contains one non-functional change and one small fix for
pci-passthrough when using the 8259A PIC. I very much doubt anyone has
done pci-passthrough on guests using the legacy PIC, but nonetheless
let's aim for it to be correct.
Thanks, Roger.
Roger Pau Monne (2):
x86/vpic:
The irq variable is wrongly named, as it's used to store the pin on
the 8259 chip, but not the global irq value. While renaming reduce
it's scope and make it unsigned.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/vpic.c | 18 ++
1 file chang
Currently the dpci EOI callback is only executed for specific EOIs.
This is wrong as non-specific EOIs will also clear the ISR bit and
thus end the interrupt. Re-arrange the code a bit so that the common
EOI handling path can be shared between all EOI modes.
Signed-off-by: Roger Pau Monné
---
xe
On Wed, Aug 19, 2020 at 08:12:04PM -0400, Eduardo Habkost wrote:
> The typedef was used in the XENBACKEND_DEVICE macro, but it was
> never defined. Define the typedef close to the type checking
> macro.
>
> Signed-off-by: Eduardo Habkost
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Thu, Aug 20, 2020 at 6:10 AM Rich Persaud wrote:
>
> On Aug 20, 2020, at 07:24, George Dunlap wrote:
>
>
>
> On Thu, Aug 20, 2020 at 9:35 AM Jan Beulich wrote:
>>
>>
>> As far as making cases like this work by default, I'm afraid it'll
>> need to be proposed to replace me as the maintainer
On 20/08/2020 16:34, Roger Pau Monne wrote:
> The irq variable is wrongly named, as it's used to store the pin on
> the 8259 chip, but not the global irq value. While renaming reduce
> it's scope and make it unsigned.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Acked-by:
On 20/08/2020 16:34, Roger Pau Monne wrote:
> Currently the dpci EOI callback is only executed for specific EOIs.
> This is wrong as non-specific EOIs will also clear the ISR bit and
> thus end the interrupt. Re-arrange the code a bit so that the common
> EOI handling path can be shared between all
On Thu, Aug 20, 2020 at 05:28:21PM +0100, Andrew Cooper wrote:
> On 20/08/2020 16:34, Roger Pau Monne wrote:
> > Currently the dpci EOI callback is only executed for specific EOIs.
> > This is wrong as non-specific EOIs will also clear the ISR bit and
> > thus end the interrupt. Re-arrange the code
On 20/08/2020 16:08, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index ca4307e19f..a890cb9976 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -274,6 +274,14 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
> *val)
> *val = ms
On Tue, 18 Aug 2020, Jan Beulich wrote:
> On 18.08.2020 00:56, Stefano Stabellini wrote:
> > On Mon, 17 Aug 2020, Jan Beulich wrote:
> >> On 07.08.2020 23:51, Stefano Stabellini wrote:
> >>> On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > @@ -200
flight 152629 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
On Thu, 20 Aug 2020, Oleksandr wrote:
> > On 11/08/2020 23:48, Stefano Stabellini wrote:
> > > > I have the impression that we disagree in what the Device Emulator is
> > > > meant to
> > > > do. IHMO, the goal of the device emulator is to emulate a device in an
> > > > arch-agnostic way.
> > >
>
On Tue, 18 Aug 2020, Julien Grall wrote:
> On 11/08/2020 23:48, Stefano Stabellini wrote:
> > On Tue, 11 Aug 2020, Julien Grall wrote:
> > > > I vaguely
> > > > recall a bug 10+ years ago about this with QEMU on x86 and a line that
> > > > could be both active-high and active-low. So QEMU would r
On Tue, 18 Aug 2020, Roman Shaposhnik wrote:
> Hi!
> first things first -- booting on those devices have always
> required efi=no-rs -- but it seems that Xen 4.14 is now
> busted at a more fundamental level. I'm attaching two
> boot sequences (one with kernel 4.19.5 and one with 5.4.51)
> in the h
Now that the iommu implementations handle the X86_*_GET_PARENT_DOMAIN
types, consolidate the two getter functions.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: Joerg Roedel
Cc: linux-hyp...@vger.kernel.org
Cc: io...@lists.linux-foundation.org
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Jo
First of all, sorry for the horrible long Cc list, which was
unfortunately unavoidable as this touches the world and some more.
This patch series aims to provide a base to support device MSI (non
PCI based) in a halfways architecture independent way.
It's a mixed bag of bug fixes, cleanups and ge
Some past platform removal forgot to get rid of this unused ballast.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/mpspec.h | 10 --
arch/x86/include/asm/x86_init.h | 10 --
arch/x86/kernel/mpparse.c | 26 --
arch/x86/kernel/x86_ini
None of the magic HPET fields are required in any way.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
Cc: Lu Baolu
---
arch/x86/include/asm/hw_irq.h |7 ---
arch/x86/kernel/apic/msi.c | 14 +++---
drivers/iommu/amd/iommu.c
Dereferencing irq_data before checking it for NULL is suboptimal.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
drivers/iommu/amd/iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/
None of the DMAR specific fields are required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |6 --
arch/x86/kernel/apic/msi.c| 10 +-
2 files changed, 5 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq
No point in initializing the default PCI/MSI interrupt domain early and no
point to create it when XEN PV/HVM/DOM0 are active.
Move the initialization to pci_arch_init() and convert it to init ops so
that XEN can override it as XEN has it's own PCI/MSI management. The XEN
override comes in a later
struct irq_alloc_info is a horrible zoo of unnamed structs in a union. Many
of the struct fields can be generic and don't have to be type specific like
hpet_id, ioapic_id...
Provide a generic set of members to prepare for the consolidation. The goal
is to make irq_alloc_info have the same basic me
No point to call it from both 32bit and 64bit implementations of
default_setup_apic_routing(). Move it to the caller.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c |3 +++
arch/x86/kernel/apic/probe_32.c |3 ---
arch/x86/kernel/apic/probe_64.c |3 ---
3 files cha
irq_remapping_ir_irq_domain() is used to retrieve the remapping parent
domain for an allocation type. irq_remapping_irq_domain() is for retrieving
the actual device domain for allocating interrupts for a device.
The two functions are similar and can be unified by using explicit modes
for parent ir
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
arch/x86/include/asm/hw_irq.h |4 ++--
arch/x86/kernel/apic/msi.c |6 +++---
drivers/iommu/amd/iommu.c | 24
drivers/iommu/i
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
drivers/iommu/amd/iommu.c | 65 ++
1 file
Move the UV specific fields into their own struct for readability sake. Get
rid of the #ifdeffery as it does not matter at all whether the alloc info
is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
Cc: Steve Wahl
Cc: Dimitri Sivanich
Cc: Russ Anderson
---
arch/x86/include/
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
Cc: Lu Baolu
---
drivers/iommu/intel/irq_remapping.c | 67 ---
Move the IOAPIC specific fields into their own struct and reuse the common
devid. Get rid of the #ifdeffery as it does not matter at all whether the
alloc info is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: "K. Y. Srinivasan"
Cc: Stephen Hemminger
Cc: Joerg
Retrieve the PCI device from the msi descriptor instead of doing so at the
call sites.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
---
arch/x86/kernel/apic/msi.c |2 +-
drivers/pci/msi.c | 13 ++---
include/linux/msi.h|3 +--
3 files changed, 8
pci_msi_get_hwirq() and pci_msi_set_desc are not longer special. Enable the
generic MSI domain ops in the core and PCI MSI code unconditionally and get
rid of the x86 specific implementations in the X86 MSI code and in the
hyperv PCI driver.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: Stephen
If an architecture does not require the MSI setup/teardown fallback
functions, then allow them to be replaced by stub functions which emit a
warning.
Signed-off-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/pci/Kconfig |3 +++
drivers/pci/msi.c |3 ++-
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into an
irq domain.
Move the x86_msi ops setup into a single function to
Convert the interrupt remap drivers to retrieve the pci device from the msi
descriptor and use info::hwirq.
This is the first step to prepare x86 for using the generic MSI domain ops.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: Stephen Hemminger
Cc: Joerg Roedel
Cc: linux-...@vger.kernel.o
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
arch_teardown_msi_irq(). default_teardown_msi_irqs() is a trivial it
For the upcoming device MSI support it's required to have a default
irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not
need to care.
Signed-off-by: Thomas Gleixner
Cc: Greg Kroah-Hartman
---
drivers/base/platform-msi.c |2 ++
1 file changed, 2 insertions(+)
--- a/driv
For the upcoming device MSI support a new allocation type is
required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -40,6 +40,7 @@ enum irq_alloc_type {
A generic IMS irq chip and irq domain implementation for IMS based devices
which utilize a MSI message store array on chip.
Allows IMS devices with a MSI message store array to reuse this code for
different array sizes.
Allocation and freeing of interrupts happens via the generic
msi_domain_alloc
The only user is in the same file and the name is too generic because this
function is only ever used for HVM domains.
Signed-off-by: Thomas Gleixner
Cc: Konrad Rzeszutek Wilk
Cc: linux-...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Sta
Add device specific MSI domain infrastructure for devices which have their
own resource management and interrupt chip. These devices are not related
to PCI and contrary to platform MSI they do not share a common resource and
interrupt chip. They provide their own domain specific resource management
Adding a function call before the first #ifdef in arch_pci_init() triggers
a 'mixed declarations and code' warning if PCI_DIRECT is enabled.
Use stub functions and move the #ifdeffery to the header file where it is
not in the way.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
---
Devices on the VMD bus use their own MSI irq domain, but it is not
distinguishable from regular PCI/MSI irq domains. This is required
to exclude VMD devices from getting the irq domain pointer set by
interrupt remapping.
Override the default bus token.
Signed-off-by: Thomas Gleixner
Cc: Bjorn He
Nothing except XEN uses the setup/teardown ops. Hide them there.
Signed-off-by: Thomas Gleixner
Cc: xen-devel@lists.xenproject.org
Cc: linux-...@vger.kernel.org
---
arch/x86/include/asm/x86_init.h |2 --
arch/x86/pci/xen.c | 23 +++
2 files changed, 15 inse
To allow utilizing the irq domain pointer in struct device it is necessary
to make XEN/MSI irq domain compatible.
While the right solution would be to truly convert XEN to irq domains, this
is an exercise which is not possible for mere mortals with limited XENology.
Provide a plain irqdomain wrap
Rename it to x86_msi_prepare() and handle the allocation type setup
depending on the device type.
Add a new arch_msi_prepare define which will be utilized by the upcoming
device MSI support. Define it to NULL if not provided by an architecture in
the generic MSI header.
One arch specific function
Now that interrupt remapping sets the irqdomain pointer when a PCI device
is added it's possible to store the default irq domain in the device struct
in pcibios_add_device().
If the bus to which a device is connected has an irq domain associated then
this domain is used otherwise the default domai
For devices which don't have a standard storage for MSI messages like the
upcoming IMS (Interrupt Message Storm) it's required to allocate storage
space before allocating interrupts and after freeing them.
This could be achieved with the existing callbacks, but that would be
awkward because they o
PCI devices behind a VMD bus are not subject to interrupt remapping, but
the irq domain for VMD MSI cannot be distinguished from a regular PCI/MSI
irq domain.
Add a new domain bus token and allow it in the bus token check in
msi_check_reservation_mode() to keep the functionality the same once VMD
As a first step to make X86 utilize the direct MSI irq domain operations
store the irq domain pointer in the device struct when a device is probed.
This is done from dmar_pci_bus_add_dev() because it has to work even when
DMA remapping is disabled. It only overrides the irqdomain of devices which
1 - 100 of 110 matches
Mail list logo
