On 14.07.19 11:15, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.
This gap is missed in XEN PV int3 exception entry path, then
On 16.07.19 06:26, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
... and complete series applied to
On 14.07.19 11:15, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.
This gap is missed in XEN PV int3 exception entry path, then
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports 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: Thomas Gleixner
Cc: Ingo Molnar
Cc:
PVH guest needs PV extentions to work, so "nopv" parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore "nopv" parameter directly.
If PVH guest boots up via the normal boot entry same as
flight 139035 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139035/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR.
vs. 138977
On 17.07.19 04:09, Zhenzhong Duan wrote:
On 2019/7/16 18:57, Juergen Gross wrote:
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
flight 139037 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139037/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 138970
test-armhf-armhf-libvirt-raw 13
flight 139038 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139038/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51dd408ae1022e5c9378492451a62b38d5b101c5
baseline version:
ovmf
Chaitanya,
> This series just replaces the existing accesses without changing
> anything.
>
> So if any of the exiting code has that bug then it will blow up
> nicely.
>
> For future callers I don't mind adding a new check and resend the
> series.
>
> Would you prefer adding a check ?
I checked
On 2019/7/16 18:57, Juergen Gross wrote:
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
flight 139032 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139032/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 139010
flight 139030 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139030/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
---
Changes in v2:
- Fixed code
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
Allow device model running in stubdomain to enable/disable MSI(-X),
bypassing pciback. While pciback is still used to access config space
from within stubdomain, it refuse to write to
PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which
is the right thing to do for PV domain
In this version, I add PHYSDEVOP_msi_control to allow stubdomain
enabling MSI after mapping it.
Related article:
https://www.qubes-os.org/news/2017/10/18/msi-support/
Changes in v2:
- new "xen/x86: Allow stubdom access to irq created for msi" patch
- applied review comments from v1
Changes is
Stubdomains need to be given sufficient privilege over the guest which it
provides emulation for in order for PCI passthrough to work correctly.
When a HVM domain try to enable MSI, QEMU in stubdomain calls
PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq as
part of
HVM domains use IOMMU and device model assistance for communicating with
PCI devices, xen-pcifront/pciback isn't directly needed by HVM domain.
But pciback serve also second function - it reset the device when it is
deassigned from the guest and for this reason pciback needs to be used
with HVM
Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous
commit.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- new patch
Changes in v4:
- adjust for updated previous patch
Changes in v5:
- rename to PHYSDEVOP_msi_control, adjust arguments
---
On 15/07/2019 19:57, Foerster, Leonard wrote:
> Here is the summary/notes from the Xen Live-Update Design session last week.
> I tried to tie together the different topics we talked about into some
> sections.
>
> https://cryptpad.fr/pad/#/2/pad/edit/fCwXg1GmSXXG8bc4ridHAsnR/
>
> --
> Leonard
>
>
On 16/07/2019 05:20, Sarah Newman wrote:
> On 7/15/19 8:48 PM, Juergen Gross wrote:
>> On 15.07.19 21:31, Sarah Newman wrote:
>>> On 7/15/19 11:57 AM, Foerster, Leonard wrote:
>>> ...
A key cornerstone for Live-update is guest transparent live migration
>>> ...
-> for live migration:
On 15/07/2019 18:52, Amit Shah wrote:
> On Mon, 2019-07-15 at 14:52 +, Jan Beulich wrote:
>> On 15.07.2019 16:42, George Dunlap wrote:
>>> On 7/15/19 3:23 PM, Jan Beulich wrote:
On 15.07.2019 16:11, George Dunlap wrote:
> There was a long discussion about security patches, with the
On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
wrote:
>
> 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
On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
wrote:
>
> This simplifies the command line parsing logic and makes it easier to
> add new test parameters.
>
> Signed-off-by: Petre Pircalabu
Thanks, this was much needed.
Acked-by: Tamas K Lengyel
On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
wrote:
>
> Cleanup xen-access code in accordance with the XEN style guide.
>
> Signed-off-by: Petre Pircalabu
Acked-by: Tamas K Lengyel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
wrote:
>
> 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
> -
On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
wrote:
>
> Signed-off-by: Petre Pircalabu
Acked-by: Tamas K Lengyel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> 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.
> + */
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
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
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
* 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 |
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
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
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
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 ++--
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
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 +-
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 @@
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
---
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
---
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
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
>>
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)
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
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.
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
---
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
+++
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.
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
@@
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
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
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
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
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
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
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
+++
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
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
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
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 { \
>> +
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)
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 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
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,
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.
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
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
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
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
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 -
> -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
> 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
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 ---
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
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
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
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
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 =
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)
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:
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
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
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,
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
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
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
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
> -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:
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 =
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
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()
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
...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
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
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
1 - 100 of 128 matches
Mail list logo
