On 15.07.2019 19:28, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>>
>> Juergen Gross writes:
>>
>>> The long term plan has been to replace Xen PV guests by PVH. The first
>>> victim of that plan are now 32-bit PV guests, as those are used only
>>> rather seldom thes
On 15.07.2019 19:10, Andrew Cooper wrote:
> %cr8 is an alias of APIC_TASKPRI, which is handled by
> lapic_{suspend,resume}() with the rest of the Local APIC state. Saving
> and restoring the TPR state in isolation is not a clever idea.
>
> Drop it all.
>
> While editing wakeup_prot.S, trim its i
First and foremost this series is trying to deal with CPU offlining
issues, which have become more prominent with the recently
added SMT enable/disable operation in xen-hptool. Later patches
in the series then carry out more or less unrelated changes
(hopefully improvements) noticed while looking a
The flag being set may prevent affinity changes, as these often imply
assignment of a new vector. When there's no possible destination left
for the IRQ, the clearing of the flag needs to happen right from
fixup_irqs().
Additionally _assign_irq_vector() needs to avoid setting the flag when
there's
Mixed meaning was implied so far by different pieces of code -
disagreement was in particular about whether to expect offline CPUs'
bits to possibly be set. Switch to a mostly consistent meaning
(exception being high priority interrupts, which would perhaps better
be switched to the same model as w
The cleanup IPI may get sent immediately before a CPU gets removed from
the online map. In such a case the IPI would get handled on the CPU
being offlined no earlier than in the interrupts disabled window after
fixup_irqs()' main loop. This is too late, however, because a possible
affinity change m
Use valid_irq_vector() rather than "> 0".
Also replace an open-coded use of IRQ_VECTOR_UNASSIGNED.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
v3: New.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -342,7 +342,7 @@ void clear_irq_vector(int irq)
The subsequent cpumask_intersects() covers the "empty" case quite fine.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -658,9 +658,6 @@ void move_masked_irq(struct irq_desc *de
desc->status &= ~I
fixup_irqs() skips interrupts without action. Hence such interrupts can
retain affinity to just offline CPUs. With "noirqbalance" in effect,
pirq_guest_bind() so far would have left them alone, resulting in a non-
working interrupt.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Acked-b
desc->arch.cpu_mask reflects the actual set of target CPUs. Don't ever
fiddle with desc->affinity itself, except to store caller requested
values. Note that assign_irq_vector() now takes a NULL incoming CPU mask
to mean "all CPUs" now, rather than just "all currently online CPUs".
This way no furth
Use scratch_cpumask where possible, to avoid creating these possibly
large stack objects. We can't use it in _assign_irq_vector() and
set_desc_affinity(), as these get called in IRQ context.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
v4: Re-base over cha
In line with "x86/IRQ: desc->affinity should strictly represent the
requested value" the internally used IRQ(s) also shouldn't be restricted
to online ones. Make set_desc_affinity() (set_msi_affinity() then does
by implication) cope with a NULL mask being passed (just like
assign_irq_vector() does)
All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
fields, and hence ought to be called with the descriptor lock held in
addition to vector_lock. This is currently the case for only
set_desc_affinity() (in the common case) and destroy_irq(), which also
clarifies what the nesting b
Since the "Cannot set affinity ..." warning is a one time one, avoid
triggering it already at boot time when parking secondary threads and
the serial console uses a (still unconnected at that time) PCI IRQ.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
--- a/x
If any particular value was to be checked against, it would need to be
IRQ_VECTOR_UNASSIGNED.
Reported-by: Roger Pau Monné
Be more strict though and use valid_irq_vector() instead.
Take the opportunity and also convert local variables to unsigned int.
Signed-off-by: Jan Beulich
Reviewed-by: R
This is largely to drop a forward declaration. There's one functional
change - clear_irq_vector() gets marked __init, as its only caller is
check_timer(). Beyond this only a few stray blanks get removed.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v3: New.
--- a/xen/arch/x86/irq.c
++
On Mon, Jul 15, 2019 at 05:41:27PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 15 July 2019 16:35
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> > ; Wei Liu ;
> > Konrad Rzeszutek Wilk ; George Dunlap
> > ; And
> On Jul 15, 2019, at 6:57 PM, Amit Shah wrote:
>
> On Mon, 2019-07-15 at 14:59 +0100, George Dunlap wrote:
>> Looking through the notes, it seems like the first part of this
>> discussion, re hypervisor upgrade / downgrade & libraries, was partly
>> covered in the distro session, in which Debi
On Tue, Jul 16, 2019 at 07:40:57AM +, Jan Beulich wrote:
> In line with "x86/IRQ: desc->affinity should strictly represent the
> requested value" the internally used IRQ(s) also shouldn't be restricted
> to online ones. Make set_desc_affinity() (set_msi_affinity() then does
> by implication) co
> -Original Message-
> From: Roger Pau Monne
> Sent: 16 July 2019 09:57
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu ;
> Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew
> Cooper ; Ian Jackson ; Tim
> (Xen.org) ;
> Julien Grall ; Jan Beulich
On Wed, Jul 03, 2019 at 04:46:13PM +0200, Varad Gautam wrote:
> It is possible to receive multiple __pirq_guest_unbind calls for the same pirq
> if the pirq has not yet been removed from the domain's pirq_tree. For a shared
> pirq (nr_guests > 1), the first call zaps the current domain from the pir
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 July 2019 15:39
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Suravee Suthikulpanit
> ; Brian Woods
> ; Kevin Tian ; Jan Beulich
> ; Andrew
> Cooper ; Wei Liu
> Subject: Re: [PATCH v2 1/4] iommu / x86: move call to scan
flight 139015 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139015/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a
test-armhf-armhf-examine 1 build-check
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 July 2019 16:21
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu ;
> Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew
> Cooper ; Ian Jackson ; Tim
> (Xen.org) ;
> Julien Grall ; Jan Beulich
On 7/15/19 7:46 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
Julien Grall writes:
At the moment, the user should save x30/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should also move the val
... using the new iommu_group infrastructure.
Because 'sibling' devices are now members of the same iommu_group,
implement the domctl by looking up the iommu_group of the pdev with the
matching SBDF and then finding all the assigned pdevs that are in the
group.
Signed-off-by: Paul Durrant
---
Cc
It's not vendor specific so it doesn't really belong there.
Scanning the PCI topology also really doesn't have much to do with IOMMU
initialization. It doesn't depend on there even being an IOMMU. This patch
moves to the call to the beginning of iommu_hardware_setup() but only
places it there beca
This series is a mixture of tidying and some preparatory work for grouping
PCI devices for the purposes of assignment.
Paul Durrant (4):
iommu / x86: move call to scan_pci_devices() out of vendor code
pci: add all-device iterator function...
iommu: introduce iommu_groups
iommu / pci: re-im
Some devices may share a single PCIe initiator id, e.g. if they are actually
legacy PCI devices behind a bridge, and hence DMA from such devices will
be subject to the same address translation in the IOMMU. Hence these devices
should be treated as a unit for the purposes of assignment. There are al
...and use it for setup_hwdom_pci_devices() and dump_pci_devices().
The unlock/process-pending-softirqs/lock sequence that was in
_setup_hwdom_pci_devices() is now done in the generic iterator function,
which does mean it is also done (unnecessarily) in the case of
dump_pci_devices(), since run_al
flight 139019 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-build fail in 138772 REGR. vs. 132889
build-amd64-pre
On 16.07.2019 11:12, Roger Pau Monné wrote:
> On Tue, Jul 16, 2019 at 07:40:57AM +, Jan Beulich wrote:
>> In line with "x86/IRQ: desc->affinity should strictly represent the
>> requested value" the internally used IRQ(s) also shouldn't be restricted
>> to online ones. Make set_desc_affinity()
On 16/07/2019 11:16, Paul Durrant wrote:
> ...and use it for setup_hwdom_pci_devices() and dump_pci_devices().
>
> The unlock/process-pending-softirqs/lock sequence that was in
> _setup_hwdom_pci_devices() is now done in the generic iterator function,
> which does mean it is also done (unnecessaril
On 16/07/2019 11:16, Paul Durrant wrote:
> +int iommu_group_assign(struct pci_dev *pdev, void *arg)
> +{
> +const struct iommu_ops *ops = iommu_get_ops();
> +int id;
> +struct iommu_group *grp;
> +
> +if ( !ops->get_device_group_id )
> +return 0;
> +
> +id = ops->get_dev
> -Original Message-
> From: Andrew Cooper
> Sent: 16 July 2019 11:25
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; George Dunlap
> ; Ian Jackson
> ; Julien Grall ; Konrad
> Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ;
> Wei Liu
> Subject: Re: [PA
flight 139043 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139043/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
138907
Test
On 16/07/2019 11:31, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 16 July 2019 11:26
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich ; George Dunlap
>> ; Ian Jackson
>> ; Julien Grall ; Konrad
>> Rzeszutek Wilk
>> ; Stefano Stabellini
On 16.07.2019 12:26, Andrew Cooper wrote:
> On 16/07/2019 11:16, Paul Durrant wrote:
>> +int iommu_group_assign(struct pci_dev *pdev, void *arg)
>> +{
>> +const struct iommu_ops *ops = iommu_get_ops();
>> +int id;
>> +struct iommu_group *grp;
>> +
>> +if ( !ops->get_device_group_id
On Wed, Jul 03, 2019 at 12:59:36PM +, Jan Beulich wrote:
> While the MWAIT idle driver already takes it to mean an actual C state,
> the ACPI idle driver so far used it as a list index. The list index,
> however, is an implementation detail of Xen and affected by firmware
> settings (i.e. not n
On 16/07/2019 11:37, Jan Beulich wrote:
> On 16.07.2019 12:26, Andrew Cooper wrote:
>> On 16/07/2019 11:16, Paul Durrant wrote:
>>> +int iommu_group_assign(struct pci_dev *pdev, void *arg)
>>> +{
>>> +const struct iommu_ops *ops = iommu_get_ops();
>>> +int id;
>>> +struct iommu_group *g
On Mon, 2019-07-15 at 17:06 +0100, George Dunlap wrote:
> On 8/25/18 1:21 AM, Dario Faggioli wrote:
> > If a pCPU has been/is being offlined, we don't want it to be
> > neither
> > assigned to any pCPU, nor in the wait list.
>
> I take it the first `pCPU` should be `vCPU`?
>
Indeed. :-)
> Also,
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.or
On 11.07.19 14:02, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch report warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc:
The BUG_ON() was misplaced when this function was introduced in commit
ec83f825 "mm.h: add helper function to test-and-clear _PGC_allocated".
It will fire incorrectly if _PGC_allocated is already clear on entry. Thus
it should be moved after the if statement.
Signed-off-by: Paul Durrant
---
Cc: A
On Tue, Jul 16, 2019 at 10:20:10AM +, Jan Beulich wrote:
> On 16.07.2019 11:12, Roger Pau Monné wrote:
> > On Tue, Jul 16, 2019 at 07:40:57AM +, Jan Beulich wrote:
> >> In line with "x86/IRQ: desc->affinity should strictly represent the
> >> requested value" the internally used IRQ(s) also
On 16.07.2019 12:41, Andrew Cooper wrote:
> On 16/07/2019 11:37, Jan Beulich wrote:
>> On 16.07.2019 12:26, Andrew Cooper wrote:
>>> On 16/07/2019 11:16, Paul Durrant wrote:
+int iommu_group_assign(struct pci_dev *pdev, void *arg)
+{
+const struct iommu_ops *ops = iommu_get_ops()
On 16.07.2019 12:39, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 12:59:36PM +, Jan Beulich wrote:
>> While the MWAIT idle driver already takes it to mean an actual C state,
>> the ACPI idle driver so far used it as a list index. The list index,
>> however, is an implementation detail of X
On Tue, Jul 16, 2019 at 11:16:57AM +0100, Paul Durrant wrote:
> ... using the new iommu_group infrastructure.
>
> Because 'sibling' devices are now members of the same iommu_group,
> implement the domctl by looking up the iommu_group of the pdev with the
> matching SBDF and then finding all the as
On 16.07.2019 13:05, Paul Durrant wrote:
> The BUG_ON() was misplaced when this function was introduced in commit
> ec83f825 "mm.h: add helper function to test-and-clear _PGC_allocated".
> It will fire incorrectly if _PGC_allocated is already clear on entry. Thus
> it should be moved after the if s
At this moment IOMMU pt sharing is disabled by commit [1].
This patch aims to clear the IOMMU hap share support as it will not be
used in the future. By doing this the IOMMU bits used in pte[52:58] can
be used in other ways.
[1] c2ba3db31ef2d9f1e40e7b6c16cf3be3d671d555
Suggested-by: George Dunla
At this moment IOMMU pt sharing is disabled by commit [1].
This patch cleans the unreachable code garded by iommu_hap_pt_share.
[1] c2ba3db31ef2d9f1e40e7b6c16cf3be3d671d555
Signed-off-by: Alexandru Isaila
---
xen/drivers/passthrough/amd/iommu_map.c | 28 ---
xen/drivers/p
> On Jul 16, 2019, at 11:50 AM, Dario Faggioli wrote:
>
> On Mon, 2019-07-15 at 17:06 +0100, George Dunlap wrote:
>> On 8/25/18 1:21 AM, Dario Faggioli wrote:
>>> If a pCPU has been/is being offlined, we don't want it to be
>>> neither
>>> assigned to any pCPU, nor in the wait list.
>>
>> I ta
> -Original Message-
> From: Roger Pau Monne
> Sent: 16 July 2019 12:28
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v3 4/4] iommu / pci: re-implement
> XEN_DOMCTL_get_device_group...
>
> On Tue, Jul 16, 2019 at 11:16:57AM +0100
Hello,
After re-syncing the XenServer patchqueue against Xen 4.12, I think the
following patches are candidates for backport.
Bugfixes:
65c165d6595f - x86/xstate: Don't special case feature collection
013896cb8b2f - x86/msr: Fix handling of
MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV
7d161f653755 - x8
flight 139051 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
138907
Test
Hi Julien,
On Mon, Jul 15, 2019 at 9:01 PM Julien Grall wrote:
>
> Hi Viktor,
>
> On 20/06/2019 11:38, Viktor Mitin wrote:
> > Functions make_timer_node and make_timer_domU_node are quite similar.
> > The only difference between Dom0 and DomU timer DT node
> > is the timer interrupts used. All t
On July 15, 2019 7:37:17 AM Paul Durrant wrote:
> It's not vendor specific so it doesn't really belong there.
>
>
> Scanning the PCI topology also really doesn't have much to do with IOMMU
> initialization. It doesn't depend on there even being an IOMMU. This patch
> moves to the call to the begi
flight 139022 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 138376
build-i386-pre
On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
> At least for more recent CPUs, following what BKDG / PPR suggest for the
> BIOS to surface via ACPI we can make ourselves independent of Dom0
> uploading respective data.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Handle Hygon Fam18.
On Wed, Jul 03, 2019 at 01:03:02PM +, Jan Beulich wrote:
> From: Ross Lagerwall
>
> Allow limiting the max C-state sub-state by appending to the max_cstate
> command-line parameter. E.g. max_cstate=1,0
> The limit only applies to the highest legal C-state. For example:
> max_cstate = 1, max
On Wed, Jul 03, 2019 at 01:04:13PM +, Jan Beulich wrote:
> From: Ross Lagerwall
>
> Signed-off-by: Ross Lagerwall
>
> Make handling in do_pm_op() more homogeneous: Before interpreting
> op->cpuid as such, handle all operations not acting on a particular
> CPU. Also expose the setting via xe
On Tue, 2019-07-16 at 12:02 +, George Dunlap wrote:
> > On Jul 16, 2019, at 11:50 AM, Dario Faggioli
> > On Mon, 2019-07-15 at 17:06 +0100, George Dunlap wrote:
> > > On 8/25/18 1:21 AM, Dario Faggioli wrote:
> > > >
> > > The other thing is, from a "developmental purity" point of view,
> > >
On 05/07/2019 14:17, Sergey Dyasli wrote:
> [2019-07-05 00:37:16 UTC] (XEN) [24907.482686] Watchdog timer detects that
> CPU30 is stuck!
> [2019-07-05 00:37:16 UTC] (XEN) [24907.514180] [ Xen-4.13.0-8.0.6-d
> x86_64 debug=y Not tainted ]
> [2019-07-05 00:37:16 UTC] (XEN) [24907.552070
On 02.07.2019 14:09, Andrew Cooper wrote:
> On 27/06/2019 16:19, Jan Beulich wrote:
>> printk("AMD-Vi: IOMMU Extended Features:\n");
>>
>> -while ( feature_str[i] )
>> +#define MASK(fld) ((union amd_iommu_ext_features){ .flds.fld = ~0 }).raw
>> +#define FEAT(fld, str) do { \
>> +if
DMA-ing to the stack is considered bad practice. In this case, if a
timeout occurs because of a sluggish device which is processing the
request, the completion notification will corrupt the stack of a
subsequent deeper call tree.
Place the poll_slot in a percpu area and DMA to that instead.
Fix
Despite the title this is actually all AMD IOMMU side work; all x86
side adjustments have already been carried out.
The first and last patches aren't really x2APIC related, but were found
helpful in the course of the re-work done for this version. The first
one lives in its place for easy backport
On 16/07/2019 14:56, Viktor Mitin wrote:
Hi Julien,
Hi,
On Mon, Jul 15, 2019 at 9:01 PM Julien Grall wrote:
Hi Viktor,
On 20/06/2019 11:38, Viktor Mitin wrote:
Functions make_timer_node and make_timer_domU_node are quite similar.
The only difference between Dom0 and DomU timer DT node
The interrupt remapping in-use bitmaps were leaked in all cases. The
ring buffers and the mapping of the MMIO space were leaked for any IOMMU
that hadn't been enabled yet.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iom
At the same time restrict its scope to just the single source file
actually using it, and abstract accesses by introducing a union of
pointers. (A union of the actual table entries is not used to make it
impossible to [wrongly, once the 128-bit form gets added] perform
pointer arithmetic / array ac
Also introduce a field in struct amd_iommu caching the most recently
written control register. All writes should now happen exclusively from
that cached value, such that it is guaranteed to be up to date.
Take the opportunity and add further fields. Also convert a few boolean
function parameters t
On 16.07.2019 18:23, Andrew Cooper wrote:
> DMA-ing to the stack is considered bad practice. In this case, if a
> timeout occurs because of a sluggish device which is processing the
> request, the completion notification will corrupt the stack of a
> subsequent deeper call tree.
>
> Place the pol
Both users will want to know IOMMU properties (specifically the IRTE
size) subsequently. Leverage this to avoid pointless calls to the
callback when IVRS mapping table entries are unpopulated. To avoid
leaking interrupt remapping tables (bogusly) allocated for IOMMUs
themselves, this requires suppr
This also takes care of several of the shift values wrongly having been
specified as hex rather than dec.
Take the opportunity and
- replace a readl() pair by a single readq(),
- add further fields.
Signed-off-by: Jan Beulich
---
v3: Another attempt at deriving masks from bitfields, hopefully be
This is in preparation of actually enabling x2APIC mode, which requires
this wider IRTE format to be used.
A specific remark regarding the first hunk changing
amd_iommu_ioapic_update_ire(): This bypass was introduced for XSA-36,
i.e. by 94d4a1119d ("AMD,IOMMU: Clean up old entries in remapping
tab
The functions will want to know IOMMU properties (specifically the IRTE
size) subsequently.
Rather than introducing a second error path bogusly returning -E... from
amd_iommu_read_ioapic_from_ire(), also change the existing one to follow
VT-d in returning the raw (untranslated) IO-APIC RTE.
Signe
The function will want to know IOMMU properties (specifically the IRTE
size) subsequently.
Correct indentation of one of the call sites at this occasion.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -74,
Early enabling (to enter x2APIC mode) requires deferring of the IRQ
setup. Code to actually do that setup in the x2APIC case will get added
subsequently.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v3: Re-base.
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthro
Mapping the MMIO space and obtaining feature information needs to happen
slightly earlier, such that for x2APIC support we can set XTEn prior to
calling amd_iommu_update_ivrs_mapping_acpi() and
amd_iommu_setup_ioapic_remapping().
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/d
Flushing didn't get done along the lines of what the specification says.
Mark entries to be updated as not remapped (which will result in
interrupt requests to get target aborted, but the interrupts should be
masked anyway at that point in time), issue the flush, and only then
write the new entry.
In order to be able to express all possible destinations we need to make
use of this non-MSI-capability based mechanism. The new IRQ controller
structure can re-use certain MSI functions, though.
For now general and PPR interrupts still share a single vector, IRQ, and
hence handler.
Signed-off-by
When there are sufficiently many devices listed in the ACPI tables (no
matter if they actually exist), output may take way longer than the
watchdog would like.
Signed-off-by: Jan Beulich
---
v3: New.
---
TBD: Seeing the volume of output I wonder whether we should further
suppress logging he
In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
switched into suitable state.
The post-AP-bringup IRQ affinity adjustment is done also for the non-
x2APIC case, matching what VT-d does.
Signed-off-by: Jan Beulich
---
v3: Set GAEn (and other control register bits) earlier.
On 16/07/2019 17:33, Jan Beulich wrote:
> On 16.07.2019 18:23, Andrew Cooper wrote:
>> DMA-ing to the stack is considered bad practice. In this case, if a
>> timeout occurs because of a sluggish device which is processing the
>> request, the completion notification will corrupt the stack of a
>> s
Define the type for each of the supported vm_event rings (paging,
monitor and sharing) and replace the ring param field with this type.
Replace XEN_DOMCTL_VM_EVENT_OP_ occurrences with their corresponding
XEN_VM_EVENT_TYPE_ counterpart.
Signed-off-by: Petre Pircalabu
---
tools/libxc/include/xen
This simplifies the command line parsing logic and makes it easier to
add new test parameters.
Signed-off-by: Petre Pircalabu
---
tools/tests/xen-access/xen-access.c | 60 +
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/tools/tests/xen-access
Split xen-access in order to accommodate both vm_event interfaces
(legacy and NG). By default, the legacy vm_event is selected but
this can be changed by adding the '-n' flag in the command line.
Signed-off-by: Petre Pircalabu
---
tools/tests/xen-access/Makefile | 7 +-
tools/tests/xen-ac
Signed-off-by: Petre Pircalabu
---
xen/common/vm_event.c | 2 ++
xen/include/xen/sched.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 515a917..787c61c 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -71,6 +71,8 @@ s
Remove the domain reference from calls to vm_event interface function
and use the backpointer from vm_event_domain.
Affected functions:
- __vm_event_claim_slot / vm_event_claim_slot / vm_event_claim_slot_nosleep
- vm_event_cancel_slot
- vm_event_put_request
Signed-off-by: Petre Pircalabu
---
xe
Decouple implementation from interface to allow vm_event_check to be
used regardless of the vm_event underlying implementation.
Signed-off-by: Petre Pircalabu
Acked-by: Andrew Cooper
Acked-by: Tamas K Lengyel
---
xen/arch/arm/mem_access.c | 2 +-
xen/arch/x86/mm/mem_access.c | 4 ++--
x
In high throughput introspection scenarios where lots of monitor
vm_events are generated, the ring buffer can fill up before the monitor
application gets a chance to handle all the requests thus blocking
other vcpus which will have to wait for a slot to become available.
This patch adds support fo
Cleanup xen-access code in accordance with the XEN style guide.
Signed-off-by: Petre Pircalabu
---
tools/tests/xen-access/xen-access.c | 57 +
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xe
To accommodate a second implementation of the vm_event subsystem, the
current one (ring) should be decoupled from the xen/vm_event.h interface.
Signed-off-by: Petre Pircalabu
---
xen/common/vm_event.c | 368 ++---
xen/include/xen/vm_event.h | 60
The vm_event_domain members are not accessed outside vm_event.c so it's
better to hide de implementation details.
Signed-off-by: Petre Pircalabu
Acked-by: Andrew Cooper
Acked-by: Tamas K Lengyel
---
xen/common/vm_event.c | 26 ++
xen/include/xen/sched.h | 26 +
This patchset adds a new mechanism of sending synchronous vm_event
requests and handling vm_event responses without using a ring.
As each synchronous request pauses the vcpu until the corresponding
response is handled, it can be stored in a slotted memory buffer
(one per vcpu) shared between the hy
flight 139054 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139054/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
* alloc_l?_table() should identify the failure, not just state that there is
one.
* get_page() should use %pd for the two domains, to render system domains in
a more obvious way.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm.c | 1
flight 139027 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
flight 139061 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139061/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
wrote:
>
> This patchset adds a new mechanism of sending synchronous vm_event
> requests and handling vm_event responses without using a ring.
> As each synchronous request pauses the vcpu until the corresponding
> response is handled, it can be sto
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 959083d..c48bc21 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -36,6 +36,37 @@
> #include "io/ring.h"
>
> /*
> + * There are currently three types of VM events.
> + */
T
1 - 100 of 147 matches
Mail list logo
