From: Thomas Gleixner
No functional change.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |4 ++--
arch/x86/kernel/apic/msi.c |6 +++---
drivers/iommu/amd/iommu.c | 24
drivers/iommu/intel/irq_remapping.c | 18
From: Thomas Gleixner
None of the magic HPET fields are required in any way.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |7 ---
arch/x86/kernel/apic/msi.c | 14 +++---
drivers/iommu/amd/iommu.c |2 +-
drivers/iommu/intel
From: Thomas Gleixner
Get rid of all the gunk and remove the 'select PCI_MSI_ARCH_FALLBACK' from
the x86 Kconfig so the weak functions in the PCI core are replaced by stubs
which emit a warning, which ensures that any fail to set the irq domain
pointer results in a warning when the
From: Thomas Gleixner
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
From: Thomas Gleixner
Nothing except XEN uses the setup/teardown ops. Hide them there.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/x86_init.h |2 --
arch/x86/pci/xen.c | 21 ++---
2 files changed, 14 insertions(+), 9 deletions(-)
--- a/arch/x86
From: Thomas Gleixner
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
---
arch/x86/include/asm/hw_irq.h
From: Thomas Gleixner
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
From: Thomas Gleixner
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. Th
From: Thomas Gleixner
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
---
arch/x86/include/asm/hw_irq.h |8
From: Thomas Gleixner
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
---
drivers/iommu/amd/iommu.c | 65 ++
1 file changed, 21 insertions(+), 44
From: Thomas Gleixner
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
From: Thomas Gleixner
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
direct delivery chip do the same and move the composition of the direct
delivery MSI message to the vector domain irq chip.
This prepares for the upcoming device MSI support to avoid having
architecture specific knowledge in the device MSI domain irq chips.
Signed-off-by: Thomas Gleixner
---
V2: New
Setting the irq_set_vcpu_affinity() callback to
irq_chip_set_vcpu_affinity_parent() is a pointless exercise because the
function which utilizes it searchs the domain hierarchy to find a parent
domain which has such a callback.
Remove the useless indirection.
Signed-off-by: Thomas Gleixner
This is the second version of providing a base to support device MSI (non
PCI based) and on top of that support for IMS (Interrupt Message Storm)
based devices in a halfways architecture independent way.
The first version can be found here:
https://lore.kernel.org/r/20200821002424.119492...@l
From: Thomas Gleixner
Now that the iommu implementations handle the X86_*_GET_PARENT_DOMAIN
types, consolidate the two getter functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irq_remapping.h |8
arch/x86/kernel/apic/io_apic.c |2 +-
arch/x86/kernel
the vector domain.
Signed-off-by: Thomas Gleixner
---
V2: New patch. Note, that this might break other stuff which relies on the
current behaviour, but the hierarchy composition of DT based chips is
really hard to follow.
---
arch/x86/kernel/apic/msi.c |7 +--
kernel/irq/chip.c
From: Thomas Gleixner
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
From: Thomas Gleixner
Dereferencing irq_data before checking it for NULL is suboptimal.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/amd/iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3717,8
es an interrupt vector in the vector domain which is
never used.
The domain is self contained and has no parent dependencies, so just hand
in NULL for the parent and be done with it.
Signed-off-by: Thomas Gleixner
Cc: Jonathan Derrick
Cc: linux-...@vger.kernel.org
---
V2: New patch.
---
driver
On Wed, Aug 26 2020 at 16:40, Boqun Feng wrote:
> I hit a compiler error while I was trying to compile this patchset:
>
> arch/x86/kernel/devicetree.c: In function ‘dt_irqdomain_alloc’:
> arch/x86/kernel/devicetree.c:232:6: error: ‘struct irq_alloc_info’ has no
> member named ‘ioapic_id’; did you
On Tue, Aug 25 2020 at 23:40, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 16:35, Bjorn Helgaas wrote:
>> On Tue, Aug 25, 2020 at 11:28:30PM +0200, Thomas Gleixner wrote:
>>>
>>> Or did you just mean that those architectures should select
>>> CONFIG_I_WAN
On Tue, Aug 25 2020 at 16:35, Bjorn Helgaas wrote:
> On Tue, Aug 25, 2020 at 11:28:30PM +0200, Thomas Gleixner wrote:
>>
>> Or did you just mean that those architectures should select
>> CONFIG_I_WANT_THE CRUFT instead of opting out on the fully irq domain
>> based ones
On Tue, Aug 25 2020 at 15:24, Bjorn Helgaas wrote:
> On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
>> Rename it to x86_msi_prepare() and handle the allocation type setup
>> depending on the device type.
>
> I see what you're doing, but the subject rea
On Tue, Aug 25 2020 at 15:07, Bjorn Helgaas wrote:
>> + * The arch hooks to setup up msi irqs. Default functions are implemented
>> + * as weak symbols so that they /can/ be overriden by architecture specific
>> + * code if needed.
>> + *
>> + * They can be replaced by stubs with warnings via
>> +
On Tue, Aug 25 2020 at 15:03, Bjorn Helgaas wrote:
> On Fri, Aug 21, 2020 at 02:24:37AM +0200, Thomas Gleixner wrote:
>> Retrieve the PCI device from the msi descriptor instead of doing so at the
>> call sites.
>
> I'd like it *better* with "PCI/MSI: " in the
On Tue, Aug 25 2020 at 06:21, Jürgen Groß wrote:
> On 24.08.20 23:21, Thomas Gleixner wrote:
>> I still think it does the right thing depending on the place it is
>> called from, but even if so, it's completely unreadable gunk. I'll fix
>> that proper.
>
> The
On Mon, Aug 24 2020 at 08:21, Jürgen Groß wrote:
> On 21.08.20 02:24, Thomas Gleixner wrote:
>
> Looking into https://www.kernel.org/doc/Documentation/IRQ-domain.txt (is
> this still valid?)
It's halfways correct. Emphasis on halfways.
> I believe Xen should be able to use t
On Mon, Aug 24 2020 at 06:59, Jürgen Groß wrote:
> On 21.08.20 02:24, Thomas Gleixner wrote:
>> +static __init void xen_setup_pci_msi(void)
>> +{
>> +if (xen_initial_domain()) {
>> +x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
>> +
On Sat, Aug 22 2020 at 20:05, Jason Gunthorpe wrote:
> On Sat, Aug 22, 2020 at 03:34:45AM +0200, Thomas Gleixner wrote:
> As a silicon design it might work, but it means existing devices can't
> be used with this dev_msi. It is also the sort of thing that would
> need a standard
Jason,
On Fri, Aug 21 2020 at 21:51, Jason Gunthorpe wrote:
> On Sat, Aug 22, 2020 at 01:47:12AM +0200, Thomas Gleixner wrote:
>> > If the device has died the driver has code to detect and trigger a
>> > PCI function reset which will definitely stop the interrupt.
>>
&
On Fri, Aug 21 2020 at 17:17, Jason Gunthorpe wrote:
> On Fri, Aug 21, 2020 at 09:47:43PM +0200, Thomas Gleixner wrote:
>> So if I understand correctly then the queue memory where the MSI
>> descriptor sits is in RAM.
>
> Yes, IMHO that is the whole point of this 'IMS&
On Fri, Aug 21 2020 at 09:45, Jason Gunthorpe wrote:
> On Fri, Aug 21, 2020 at 02:25:02AM +0200, Thomas Gleixner wrote:
>> +static void ims_mask_irq(struct irq_data *data)
>> +{
>> +struct msi_desc *desc = irq_data_get_msi_desc(data);
>> +struct ims_arra
wrapper around XEN. While this is blatant
violation of the irqdomain design, it's the only solution for a XEN igorant
person to make progress on the issue which triggered this change.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
Note: Th
Provide a helper function to check whether a PCI device is handled by a
non-standard PCI/MSI domain. This will be used to exclude such devices
which hang of a special bus, e.g. VMD, to be excluded from the irq domain
override in irq remapping.
Signed-off-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc
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
better variant is to reimplement platform MSI on top of
device MSI.
Signed-off-by: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Marc Zyngier
Cc: "Rafael J. Wysocki"
---
drivers/base/platform-msi.c | 129
include/linux/irqdomain.h |1
g MSI descriptors, MSI storage
space etc.
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
---
include/linux/msi.h | 27
kernel/irq/msi.c| 70 +++-
2 files changed, 75 insertions(+), 22 deletions(-)
--- a/include/linux/msi.h
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
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
Get rid of all the gunk and enable CONFIG_PCI_MSI_DISABLE_ARCH_FALLBACKS.
Signed-off-by: Thomas Gleixner
Cc: xen-de...@lists.xenproject.org
Cc: linux-...@vger.kernel.org
---
arch/x86/Kconfig|1 +
arch/x86/include/asm/pci.h | 11 ---
arch/x86/include/asm
f the x86_msi ops private to XEN in the next
steps.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
---
arch/x86/include/asm/irqdomain.h |2 ++
arch/x86/kernel/apic/msi.c |2 +-
arch/x86/pci/common.c| 18 +-
3 files changed, 20 insertions(
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
function for MSI support is truly enough.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Cc: linux-hyp...@vger.kernel.org
---
arch/x86/include/asm/msi.h |4 +++-
arch/x86/kernel/apic/msi.c | 27 ---
drivers/pci/controller/pci-hyperv.c |2
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
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
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.
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
None of the magic HPET fields are required in any way.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@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
to prepare for this.
Signed-off-by: Thomas Gleixner
---
arch/x86/pci/xen.c | 51 ---
1 file changed, 32 insertions(+), 19 deletions(-)
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -371,7 +371,10 @@ static void xen_initdom_restore_msi_irqs
VMD which have their own irq domain.
No functional change.
It just avoids the redirection through arch_*_msi_irqs() and allows the
PCI/MSI core to directly invoke the irq domain alloc/free functions instead
of having to look up the irq domain for every single MSI interupt.
Signed-off-by: Thomas
acks which operate on struct device. The resulting
storage information has to be stored in struct msi_desc so the underlying
irq chip implementation can retrieve it for the relevant operations.
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
---
include/linux/msi.h |8
kernel/irq/msi.c
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
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
basic member as the generic
msi_alloc_info so generic MSI domain ops can be reused and yet more mess
can be avoided when (non-PCI) device MSI support comes along.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h | 22 --
1 file changed, 16 insertions(+), 6 dele
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(+)
instead of having to look up the irq domain for
every single MSI interupt.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Cc: Lu Baolu
---
drivers/iommu/intel/dmar.c |3 +++
drivers/iommu/intel/irq_remapping.c | 16
include
Dereferencing irq_data before checking it for NULL is suboptimal.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@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
in a later step.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
---
arch/x86/include/asm/irqdomain.h |6 --
arch/x86/include/asm/x86_init.h |3 +++
arch/x86/kernel/apic/msi.c | 26 --
arch/x86/kernel/apic/vector.c|2 --
arch/x86/k
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
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: iommu@lists.linux-foundation.org
Cc: "K. Y. Srinivasan"
Cc: Haiyang
use the irq domain functions directly.
Signed-off-by: Thomas Gleixner
---
arch/x86/pci/xen.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -376,20 +376,31 @@ static void xen_initdom_restore_msi_irqs
static
uses this token.
Signed-off-by: Thomas Gleixner
Cc: Jon Derrick
---
include/linux/irqdomain.h |1 +
kernel/irq/msi.c |7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -84,6 +84,7 @@ enum
Nothing except XEN uses the setup/teardown ops. Hide them there.
Signed-off-by: Thomas Gleixner
Cc: xen-de...@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
as an exercise for the people who care about this deeply.
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: Megha Dey
Cc: Jason Gunthorpe
Cc: Dave Jiang
Cc: Alex Williamson
Cc: Jacob Pan
Cc: Baolu Lu
Cc: Kevin Tian
Cc: Dan Williams
---
drivers/irqchip/Kconfig |8
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-de...@lists.xenproject.org
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano
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
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@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
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
irq domain retrieval.
Add X86_IRQ_ALLOC_TYPE_IOAPIC/HPET_GET_PARENT and use it in the iommu
implementations. Drop the parent domain retrieval for PCI_MSI/X as that is
unused.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: x...@kernel.org
Cc: linux-hyp...@vger.kernel.org
Cc: iommu@lists.linux
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: iommu@lists.linux-foundation.org
Cc: Lu Baolu
---
drivers/iommu/intel/irq_remapping.c | 67
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: iommu@lists.linux-foundation.org
---
drivers/iommu/amd/iommu.c | 65 ++
1 file
"Jacob Pan (Jun)" writes:
> On Sun, 26 Apr 2020 16:55:25 +0200
> Thomas Gleixner wrote:
>> Fenghua Yu writes:
>> > The PASID is freed when the process exits (so no need to keep
>> > reference counts on how many SVM devices are sharing the PASID).
&g
Ashok,
"Raj, Ashok" writes:
> On Sun, Apr 26, 2020 at 05:25:06PM +0200, Thomas Gleixner wrote:
>> Just for the record I also suggested to have a proper errorcode in the
>> #GP for ENQCMD and I surely did not suggest to avoid decoding the user
>> instructions.
"Luck, Tony" writes:
>> Just for the record I also suggested to have a proper errorcode in the
>> #GP for ENQCMD and I surely did not suggest to avoid decoding the user
>> instructions.
>
> Is the heuristic to avoid decoding the user instructions OK (you are just
> pointing
> out that you should
Fenghua Yu writes:
> On Sun, Apr 26, 2020 at 05:25:06PM +0200, Thomas Gleixner wrote:
>> > @@ -499,6 +510,12 @@ dotraplinkage void do_general_protection(struct
>> > pt_regs *regs, long error_code)
>> >int ret;
>> >
>> >RCU_LOCKDEP_WARN
Fenghua Yu writes:
> On Sun, Apr 26, 2020 at 04:55:25PM +0200, Thomas Gleixner wrote:
>> Fenghua Yu writes:
>> > + +#ifdef CONFIG_INTEL_IOMMU_SVM + int pasid;
>>
>> int? It's a value which gets programmed into the MSR along with the valid
>> bit (bit
he PASID MSR and returning. If the #GP was from
>an ENQCMD this will fix it. If not, the #GP fault will be repeated
>and we will hit case "2".
>
> Suggested-by: Thomas Gleixner
Just for the record I also suggested to have a proper errorcode in the
#GP for EN
Fenghua Yu writes:
> PASID is shared by all threads in a process. So the logical place to keep
> track of it is in the "mm". Add the field to the architecture specific
> mm_context_t structure.
>
> A PASID is allocated for an "mm" the first time any thread attaches
> to an SVM capable device. Lat
Fenghua Yu writes:
> The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
> (PASID), a 20-bit value. Bit 31 must be set to indicate the value
> programmed in the MSR is valid. Hardware uses PASID to identify which
> process submits the work and direct responses to the right pr
Fenghua Yu writes:
> From: Yu-cheng Yu
>
> The IA32_PASID MSR is used when a task submits work via the ENQCMD
> instruction.
Is used?
> The per task MSR is stored in the task's supervisor FPU
per task MSR? Lot's of MSRs
> PASID state and is context switched by XSAVES/XRSTORS.
>
_
Fenghua Yu writes:
> A user space application can execute ENQCMD instruction to submit work
> to device. The kernel executes ENQCMDS instruction to submit work to
> device.
So a user space application _can_ execute ENQCMD and the kernel
executes ENQCMDS. And both submit work to device.
> There i
Fenghua Yu writes:
s/Add a documentation/Add documentation/
> From: Ashok Raj
>
> ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
> features are a complicated stack with lots of interconnected pieces.
> This documentation provides a big picture overview for all of the
>
Borislav Petkov writes:
> On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
>> TBH, I don't see how
>>
>> if (force_dma_decrypted(dev))
>> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
>>
>&
Borislav Petkov writes:
> On Thu, Mar 19, 2020 at 11:06:15AM +, Robin Murphy wrote:
>> Let me add another vote from a native English speaker that "unencrypted" is
>> the appropriate term to imply the *absence* of encryption, whereas
>> "decrypted" implies the *reversal* of applied encryption.
Borislav Petkov writes:
> On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
>> On 3/17/20 4:18 AM, Borislav Petkov wrote:
>> > Back then when the whole SME machinery started getting mainlined, it
>> > was agreed that for simplicity, clarity and sanity's sake, the terms
>> > denoting en
On Mon, 14 Oct 2019, Guilherme G. Piccoli wrote:
> Modules linked in: <...>
> CPU: 40 PID: 78274 Comm: qemu-system-x86 Tainted: P W OE
Tainted: P - Proprietary module loaded ...
Try again without that module
Tainted: W - Warning issued before
Are you sure that that warning is harmless
On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
> index b310a9c18113..f2e399fb626b 100644
> --- a/include/linux/mem_encrypt.h
> +++ b/include/linux/mem_encrypt.h
> @@ -21,23 +21,11 @@
>
> #else/* !CONFIG_ARCH_HAS_
On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
> powerpc and s390 are going to use this feature as well, so put it in a
> generic location.
>
> Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Thomas Gleixner
On Thu, 11 Jul 2019, Christoph Hellwig wrote:
> Hi Tom,
>
> this looks good to me. I'll wait a bit for feedback from the x86 folks,
> and if everything is fine I'll apply it to the dma-mapping tree.
Go ahead.
llocations")
> Suggested-by: Christoph Hellwig
> Signed-off-by: Tom Lendacky
> ---
>
> Based on tree git://git.infradead.org/users/hch/dma-mapping.git for-next
>
> arch/x86/Kconfig | 1 +
For the x86 parts:
Acked-by: Thomas Gleixner
On Fri, 21 Jun 2019, Ricardo Neri wrote:
> On Fri, Jun 21, 2019 at 10:05:01PM +0200, Thomas Gleixner wrote:
> > On Fri, 21 Jun 2019, Jacob Pan wrote:
> > > >
> > > I looked at the code again, seems the per cpu HPET code already taken
> > > care of HPET MSI m
On Fri, 21 Jun 2019, Jacob Pan wrote:
> On Fri, 21 Jun 2019 10:31:26 -0700
> Jacob Pan wrote:
>
> > On Fri, 21 Jun 2019 17:33:28 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> > > On Wed, 19 Jun 2019, Jacob Pan wrote:
> > > > On Tue, 18 Jun 20
On Wed, 19 Jun 2019, Jacob Pan wrote:
> On Tue, 18 Jun 2019 01:08:06 +0200 (CEST)
> Thomas Gleixner wrote:
> >
> > Unless this problem is not solved and I doubt it can be solved after
> > talking to IOMMU people and studying manuals,
>
> I agree. modify irte mig
On Tue, 18 Jun 2019, Ricardo Neri wrote:
> On Sun, Jun 16, 2019 at 11:55:03AM +0200, Thomas Gleixner wrote:
> > On Thu, 23 May 2019, Ricardo Neri wrote:
> > >
> > > struct irq_cfg {
> > > - unsigned intdest_apicid;
> > > - unsigne
On Tue, 18 Jun 2019, Ricardo Neri wrote:
> On Fri, Jun 14, 2019 at 05:54:05PM +0200, Thomas Gleixner wrote:
> >
> > So we already have ticks per second, aka frequency, right? So why do we
> > need yet another function instead of using the value which is computed
> >
Stephane,
On Mon, 17 Jun 2019, Stephane Eranian wrote:
> On Mon, Jun 17, 2019 at 1:25 AM Thomas Gleixner wrote:
> > Great that there is no trace of any mail from Andi or Stephane about this
> > on LKML. There is no problem with talking offlist about this stuff, but
> > the
On Sun, 16 Jun 2019, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> > When the hardlockup detector is enabled, the function
> > hld_hpet_intremapactivate_irq() activates the recently created entry
> > in the interrupt remapping table via the modify_ir
On Thu, 23 May 2019, Ricardo Neri wrote:
> When the hardlockup detector is enabled, the function
> hld_hpet_intremapactivate_irq() activates the recently created entry
> in the interrupt remapping table via the modify_irte() functions. While
> doing this, it specifies which CPU the interrupt must t
On Thu, 23 May 2019, Ricardo Neri wrote:
> When interrupt remapping is enabled, MSI interrupt messages must follow a
> special format that the IOMMU can understand. Hence, when the HPET hard
> lockup detector is used with interrupt remapping, it must also follow this
> special format.
>
> The IOM
301 - 400 of 588 matches
Mail list logo
