From: Brian Woods
I will no longer be working at AMD and am removing myself.
Signed-off-by: Brian Woods
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 77413e0..251bfe2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -146,14 +146,12 @@ F:
On Tue, Aug 06, 2019 at 03:05:36PM +0200, Jan Beulich wrote:
> Only the first patch here is left from v4, everything else is new,
> yet still related. The main goal is to reduce the huge memory
> overhead that we've noticed. On the way there a number of other
> things were once again noticed. Unfor
On Mon, Aug 12, 2019 at 06:52:05PM +0100, Andy Cooper wrote:
> ... to avoid having multiple spin_unlock_irqrestore() calls.
>
> Signed-off-by: Andrew Cooper
Acked-by: Brian Woods
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
On Tue, Aug 06, 2019 at 03:08:11PM +0200, Jan Beulich wrote:
> The blank line between it and the prior if() clearly indicates that this
> was meant to be a standalone if().
>
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
> ---
> v5: New.
>
> --- a/xen/drivers/passthrough/amd/pci_amd_iomm
On Tue, Aug 06, 2019 at 03:07:48PM +0200, Jan Beulich wrote:
> First and foremost switch boolean fields to bool. Adjust a few related
> function parameters as well. Then
> - in amd_iommu_set_intremap_table() don't use literal numbers,
> - in iommu_dte_add_device_entry() use a compound literal inste
On Thu, Jul 25, 2019 at 01:33:50PM +, Jan Beulich wrote:
> First and foremost switch boolean fields to bool. Adjust a few related
> function parameters as well. Then
> - in amd_iommu_set_intremap_table() don't use literal numbers,
> - in iommu_dte_add_device_entry() use a compound literal inste
On Mon, Aug 05, 2019 at 05:44:30PM +0100, Andy Cooper wrote:
> Since c/s 9fa94e10585 "x86/ACPI: also parse AMD IOMMU tables early", this
> function is unconditionally called in all cases where a DMAR ACPI table
> doesn't exist.
>
> As a consequnce, "AMD-Vi: IOMMU not found!" is printed in all case
On Thu, Jul 25, 2019 at 01:33:24PM +, Jan Beulich wrote:
> Log SBDF headers only when there are actual IRTEs to log. This is
> particularly important for the total volume of output when the ACPI
> tables describe far more than just the existing devices. On my Rome
> system so far there was one
On Thu, Jul 25, 2019 at 01:31:02PM +, Jan Beulich wrote:
> 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
On Thu, Jul 25, 2019 at 01:29:16PM +, Jan Beulich wrote:
> 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 Be
On Thu, Jul 25, 2019 at 01:33:02PM +, Jan Beulich wrote:
> 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
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
On Tue, Jul 16, 2019 at 12:01:11PM +, Alexandru Stefan ISAILA wrote:
> 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 ot
On Tue, Jul 16, 2019 at 12:01:15PM +, Alexandru Stefan ISAILA wrote:
> 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
Ac
On Tue, Jul 16, 2019 at 04:41:21PM +, Jan Beulich wrote:
> 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
Acked-by: Brian Woods
> ---
> v3: Ne
On Tue, Jul 16, 2019 at 04:40:33PM +, Jan Beulich wrote:
> 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-b
On Tue, Jul 16, 2019 at 04:39:58PM +, Jan Beulich wrote:
> 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 interru
On Tue, Jul 16, 2019 at 04:39:34PM +, Jan Beulich wrote:
> 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
Acked-by: Brian W
On Tue, Jul 16, 2019 at 04:39:10PM +, Jan Beulich wrote:
> 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().
On Tue, Jul 16, 2019 at 04:37:51PM +, Jan Beulich wrote:
> 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
On Tue, Jul 16, 2019 at 04:37:26PM +, Jan Beulich wrote:
> 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
Acked-by: Brian Woods
> ---
> v3: New.
On Tue, Jul 16, 2019 at 04:37:04PM +, Jan Beulich wrote:
> 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
On Tue, Jul 16, 2019 at 04:36:34PM +, Jan Beulich wrote:
> 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, on
On Tue, Jul 16, 2019 at 04:36:06PM +, Jan Beulich wrote:
> 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 a
On Tue, Jul 16, 2019 at 04:35:08PM +, Jan Beulich wrote:
> 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
Acked-by: Brian Woods
>
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
On Thu, Jun 27, 2019 at 09:19:06AM -0600, Jan Beulich wrote:
> The common case is all IOMMUs having the same features. Log them only
> for the first IOMMU, or for any that have a differing feature set.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
> ---
>
On Thu, Jun 20, 2019 at 01:06:21PM +0100, Andy Cooper wrote:
> Following on from c/s 7d161f6537 "x86/svm: Fix svm_vmcb_dump() when used in
> current context", there is now only a single user of svm_vmsave() remaining in
> the tree, with all users moved to svm_vm{load,save}_pa().
>
> nv->nv_n1vmcx
On Wed, Jun 26, 2019 at 01:30:28PM +0100, Andy Cooper wrote:
> On 04/06/2019 13:15, Jan Beulich wrote:
> > For find_iommu_for_device() to consistently (independent of ACPI tables)
> > return NULL for the PCI devices corresponding to IOMMUs, make sure
> > IOMMUs don't get mapped to themselves by ivr
On Fri, Jun 21, 2019 at 08:56:22AM -0600, Jan Beulich wrote:
> >>> On 21.06.19 at 16:29, wrote:
> > On Fri, Jun 21, 2019 at 12:37:47AM -0600, Jan Beulich wrote:
> >> >>> On 19.06.19 at 17:54, wrote:
> >> > On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
> >> >> >>> On 18.06.19 at 19:
On Fri, Jun 21, 2019 at 12:37:47AM -0600, Jan Beulich wrote:
> >>> On 19.06.19 at 17:54, wrote:
> > On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
> >> >>> On 18.06.19 at 19:22, wrote:
> >> > On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beulich wrote:
> >> >> >>> On 10.06.19 at 18:
On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
> [CAUTION: External Email]
>
> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
> was redundant with amd_iommu_detect_one_acpi() already calling
> pci_ro_device().
>
> Signed-off-by: Jan Beulich
Acked-by: Bria
On Mon, Jun 17, 2019 at 01:54:39PM +0100, Andy Cooper wrote:
> VMExit doesn't switch all state. The FS/GS/TS/LDTR/GSBASE segment
> information, and SYSCALL/SYSENTER MSRs may still be cached in hardware, rather
> than up-to-date in the VMCB.
>
> Export svm_sync_vmcb() via svmdebug.h so svm_vmcb_du
On Thu, May 23, 2019 at 11:20:15AM +0100, Andy Cooper wrote:
> [CAUTION: External Email]
>
> The various pieces of the hypercall page infrastructure have grown
> organically over time and ended up in a bit of a mess.
>
> * Rename all functions to be of the form *_init_hypercall_page(). This
>
On Fri, Jun 07, 2019 at 11:22:32AM +0200, Roger Pau Monne wrote:
> The new format specifier is '%pp', and prints a pci_sbdf_t using the
> seg:bus:dev.func format. Replace all SBDFs printed using
> '%04x:%02x:%02x.%u' to use the new format specifier.
>
> No functional change intended.
>
> Signed-o
On Fri, Jun 07, 2019 at 11:22:31AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
On Fri, Jun 07, 2019 at 11:22:28AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
On Fri, Jun 07, 2019 at 11:22:27AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
On Fri, Jun 07, 2019 at 11:22:26AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods
> ---
> Cc: Jan Beulich
> Cc: Andrew Coope
On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
> >>> On 18.06.19 at 19:22, wrote:
> > On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beulich wrote:
> >> >>> On 10.06.19 at 18:28, wrote:
> >> > On 23/05/2019 13:18, Jan Beulich wrote:
> >> >> TBD: Can we set local_apic_timer_c2_ok to t
On Fri, May 31, 2019 at 09:52:04AM -0600, Jan Beulich wrote:
> [CAUTION: External Email]
>
> Don't do this once per IOMMU, nor after setting up the IOMMU interrupt
> (which will want to schedule this tasklet). In fact it can be
> initialized at build time.
>
> Signed-off-by: Jan Beulich
Acked-b
On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beulich wrote:
> >>> On 10.06.19 at 18:28, wrote:
> > On 23/05/2019 13:18, 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
> >> upl
On Thu, May 30, 2019 at 10:08:12PM -0400, Rich Persaud wrote:
> [CAUTION: External Email]
> On Mar 28, 2019, at 11:04, Woods, Brian
> mailto:brian.wo...@amd.com>> wrote:
>
> This patch series add support and enablement for mwait on AMD Naples
> and Rome processors. Newe
On Thu, Jun 13, 2019 at 07:22:31AM -0600, Jan Beulich wrote:
> This also takes care of several of the shift values wrongly having been
> specified as hex rather than dec.
>
> Take the opportunity and add further fields.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_
On Thu, May 09, 2019 at 05:00:07PM -0500, Brian Woods wrote:
> On Thu, Mar 28, 2019 at 03:04:32PM +, Brian Woods wrote:
> > This patch series add support and enablement for mwait on AMD Naples
> > and Rome processors. Newer AMD processors support mwait, but only for
> > c1, and for c2 halt is
On Mon, May 20, 2019 at 11:13:36AM +0100, Andy Cooper wrote:
> Lightweight Profiling was introduced in Bulldozer (Fam15h), but was dropped
> from Zen (Fam17h) processors. Furthermore, LWP was dropped from Fam15/16 CPUs
> when IBPB for Spectre v2 was introduced in microcode, owing to LWP not being
On Thu, Mar 28, 2019 at 03:04:32PM +, Brian Woods wrote:
> This patch series add support and enablement for mwait on AMD Naples
> and Rome processors. Newer AMD processors support mwait, but only for
> c1, and for c2 halt is used. The mwait-idle driver is modified to be
> able to use both mwa
On Mon, May 06, 2019 at 07:51:17AM -0600, Lars Kurth wrote:
> [CAUTION: External Email]
>
> Hi all,
>
> Please propose topics by either editing the running agenda document at
> https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
> or by replying to the mail. Id
On 4/8/19 6:19 AM, Jan Beulich wrote:
> If any IOMMUs were successfully initialized before encountering failure,
> the successfully enabled ones should be disabled again before cleaning
> up their resources.
>
> Move disable_iommu() next to enable_iommu() to avoid a forward
> declaration, and take
On 2/1/19 8:49 AM, Andrew Cooper wrote:
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
>
>
On 3/28/19 10:04 AM, Woods, Brian wrote:
> This patch series add support and enablement for mwait on AMD Naples
> and Rome processors. Newer AMD processors support mwait, but only for
> c1, and for c2 halt is used. The mwait-idle driver is modified to be
> able to use both mwait
On 3/28/19 9:54 AM, Jan Beulich wrote:
> Move this into iommu_hardware_setup() and make that function non-
> inline. Move its declaration into common code.
>
> Signed-off-by: Jan Beulich
>
Acked-by: Brian Woods
___
Xen-devel mailing list
Xen-devel@li
On 3/28/19 9:51 AM, Jan Beulich wrote:
> Do away with the CPU vendor dependency, and set the init ops pointer
> based on what ACPI tables have been found.
>
> Also take the opportunity and add __read_mostly to iommu_ops.
>
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
On 3/28/19 9:49 AM, Jan Beulich wrote:
> In order to be able to initialize x2APIC mode we need to parse
> respective ACPI tables early. Split amd_iov_detect() into two parts for
> this purpose, and call the initial part earlier on.
>
> Signed-off-by: Jan Beulich
>
Acked-by: Brian Woods
On 3/28/19 10:50 AM, Jan Beulich wrote:
On 28.03.19 at 16:02, wrote:
>> On 3/28/19 3:26 AM, Jan Beulich wrote:
>> On 27.03.19 at 18:28, wrote:
This also lacks some of the features of mwait-idle has and duplicates
the limited functionality.
>>>
>>> Would you mind clarifying the
From: Brian Woods
Some AMD processors can use a mixture of mwait and halt for accessing
various c-states. In preparation for adding support for AMD processors,
update the mwait-idle driver to optionally use halt.
Signed-off-by: Brian Woods
---
xen/arch/x86/acpi/cpu_idle.c | 2 +-
xen/arch/x
From: Brian Woods
Add the needed data structures for enabling Naples (F17h M01h). Since
Rome (F17h M31h) has the same c-state latencies and entry methods, the
c-state information can be used for Rome as well. For both Naples and
Rome, mwait is used for c1 (cc1) and halt is functionally the same
From: Brian Woods
Newer AMD processors (F17h) have mwait support which is compatible with
Intel. Add some checks to make sure vendor specific code is run
correctly and some infrastructure to facilitate adding AMD processors.
This is done so that Xen will not be reliant on dom0 passing the parse
This patch series add support and enablement for mwait on AMD Naples
and Rome processors. Newer AMD processors support mwait, but only for
c1, and for c2 halt is used. The mwait-idle driver is modified to be
able to use both mwait and halt for idling.
Brian Woods (3):
mwait-idle: add support f
On 3/28/19 3:26 AM, Jan Beulich wrote:
On 27.03.19 at 18:28, wrote:
>> This also lacks some of the features of mwait-idle has and duplicates
>> the limited functionality.
>
> Would you mind clarifying the lack-of-features aspect? The
> only difference to your patches that I can spot is that
On 3/27/19 9:48 AM, Jan Beulich wrote:
On 26.03.19 at 22:56, wrote:
>> On 3/26/19 10:54 AM, Jan Beulich wrote:
>> On 19.03.19 at 17:12, wrote:
On 3/15/19 3:37 AM, Jan Beulich wrote:
> Furthermore I'm then once again wondering what the gain is
> over using the ACPI driver: Th
On 3/26/19 10:54 AM, Jan Beulich wrote:
On 19.03.19 at 17:12, wrote:
>> On 3/15/19 3:37 AM, Jan Beulich wrote:
>>> Furthermore I'm then once again wondering what the gain is
>>> over using the ACPI driver: The suggested _CST looks to exactly
>>> match the data you enter into the table in the
On 3/19/19 3:22 PM, Brian Woods wrote:
> On 3/11/19 2:57 AM, Chao Gao wrote:
>> Major changes in version 6:
>> - run wbinvd before updating microcode (patch 10)
>> - add an userspace tool for late microcode update (patch 1)
>> - scale time to wait by the number of remaining CPUs to respond
>>
On 3/11/19 2:57 AM, Chao Gao wrote:
> Major changes in version 6:
> - run wbinvd before updating microcode (patch 10)
> - add an userspace tool for late microcode update (patch 1)
> - scale time to wait by the number of remaining CPUs to respond
> - remove 'cpu' parameters from some related
On 3/15/19 3:37 AM, Jan Beulich wrote:
On 14.03.19 at 20:00, wrote:
>> On 3/13/19 4:35 AM, Jan Beulich wrote:
>> On 25.02.19 at 21:23, wrote:
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -103,6 +103,11 @@ static const struct cpuidle_state {
>>
On 3/15/19 3:54 AM, Jan Beulich wrote:
On 14.03.19 at 20:29, wrote:
>> On 3/13/19 4:51 AM, Jan Beulich wrote:
>> On 25.02.19 at 21:24, wrote:
Add the needed data structures for enabling Naples (F17h M01h). Since
Rome (F17h M31h) has the same c-state latencies and entry methods
On 3/13/19 4:51 AM, Jan Beulich wrote:
On 25.02.19 at 21:24, wrote:
>> Add the needed data structures for enabling Naples (F17h M01h). Since
>> Rome (F17h M31h) has the same c-state latencies and entry methods, the
>> c-state information can be used for Rome as well. For both Naples and
>>
On 3/13/19 4:42 AM, Jan Beulich wrote:
On 25.02.19 at 21:23, wrote:
>> Newer AMD processors (F17h) have mwait support. Add some checks to make
>> sure vendor specific code is run correctly and some infrastructure to
>> facilitate adding AMD processors.
>
> Both my Fam15 and my Fam10 system
On 3/13/19 4:35 AM, Jan Beulich wrote:
On 25.02.19 at 21:23, wrote:
>> --- a/xen/arch/x86/cpu/mwait-idle.c
>> +++ b/xen/arch/x86/cpu/mwait-idle.c
>> @@ -103,6 +103,11 @@ static const struct cpuidle_state {
>>
>> #define CPUIDLE_FLAG_DISABLED 0x1
>> /*
>> + * On certain AMD
On 3/5/19 11:12 AM, Wei Liu wrote:
> On Wed, Feb 27, 2019 at 06:23:35PM +0000, Woods, Brian wrote:
>> On 2/27/19 7:47 AM, Wei Liu wrote:
>>> On Mon, Feb 25, 2019 at 08:23:58PM +, Woods, Brian wrote:
>>>> Some AMD processors can use a mixture of mwait and hal
On 2/27/19 7:47 AM, Wei Liu wrote:
> On Mon, Feb 25, 2019 at 08:23:58PM +0000, Woods, Brian wrote:
>> Some AMD processors can use a mixture of mwait and halt for accessing
>> various c-states. In preparation for adding support for AMD processors,
>> update the mwait-idle dri
On 2/27/19 2:51 AM, Jan Beulich wrote:
On 26.02.19 at 17:54, wrote:
>> On 2/26/19 10:37 AM, Jan Beulich wrote:
>> On 26.02.19 at 17:25, wrote:
Correct me if I'm wrong, but the Xen's acpi-idle implementation is
dependent on dom0 using a AML interpreter and then giving that data
On 2/26/19 10:37 AM, Jan Beulich wrote:
On 26.02.19 at 17:25, wrote:
>> Correct me if I'm wrong, but the Xen's acpi-idle implementation is
>> dependent on dom0 using a AML interpreter and then giving that data back
>> to Xen. I've heard that this doesn't always work correctly on PV dom0s
>>
On 2/26/19 4:49 AM, Jan Beulich wrote:
On 25.02.19 at 21:23, wrote:
>> This patch series add support and enablement for mwait on AMD Naples
>> and Rome processors. Newer AMD processors support mwait, but only for
>> c1, and for c2 halt is used. The mwait-idle driver is modified to be
>> abl
Newer AMD processors (F17h) have mwait support. Add some checks to make
sure vendor specific code is run correctly and some infrastructure to
facilitate adding AMD processors.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/mwait-idle.c | 25 +++--
1 file changed, 23 inserti
Add the needed data structures for enabling Naples (F17h M01h). Since
Rome (F17h M31h) has the same c-state latencies and entry methods, the
c-state information can be used for Rome as well. For both Naples and
Rome, mwait is used for c1 (cc1) and halt is functionally the same as
c2 (cc6). If c2
Some AMD processors can use a mixture of mwait and halt for accessing
various c-states. In preparation for adding support for AMD processors,
update the mwait-idle driver to optionally use halt.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/mwait-idle.c | 40 +-
This patch series add support and enablement for mwait on AMD Naples
and Rome processors. Newer AMD processors support mwait, but only for
c1, and for c2 halt is used. The mwait-idle driver is modified to be
able to use both mwait and halt for idling.
Brian Woods (3):
mwait-idle: add support f
On 2/13/19 3:45 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Woods, Brian [mailto:brian.wo...@amd.com]
>> Sent: 12 February 2019 20:14
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Suthikulpanit, Suravee ; Jan Beulich
>> ; An
On 2/4/19 5:19 AM, Paul Durrant wrote:
> The current use of get/set_field_from/in_reg_u32() is both inefficient and
> requires some ugly casting.
>
> This patch defines a new bitfield structure (amd_iommu_dte) and uses this
> structure in all DTE manipulation, resulting in much more readable and
>
On 2/4/19 5:19 AM, Paul Durrant wrote:
> The current use of get/set_field_from/in_reg_u32() is both inefficient and
> requires some ugly casting.
>
> This patch defines a new bitfield structure (amd_iommu_pte) and uses this
> structure in all PTE/PDE manipulation, resulting in much more readable
>
On 1/31/19 12:24 PM, Andrew Cooper wrote:
> Passing a 32-bit integer index into an array with entries containing less than
> 32 bits of data is wasteful, and creates an unnecessary error condition of
> passing an out-of-range index.
>
> The width of the X86EMUL_OPC() encoding is currently 20 bits
On 12/31/18 5:37 AM, Andrew Cooper wrote:
> The existing __get_instruction_length_from_list() has a single user
> which uses the list functionality. That user however should be looking
> specifically for INVD or WBINVD, as reported by the vmexit exit reason.
>
> Modify svm_vmexit_do_invalidate_ca
On 11/21/18 7:21 AM, Andrew Cooper wrote:
> Most of these issues would be XSAs if these paths were accessible to guests.
>
> First, override the {get,put}_gfn() helpers to use gfn_t, which was the
> original purpose of this patch.
>
> guest_iommu_get_table_mfn() has two bugs. First, it gets a re
On 1/28/19 8:25 AM, Andrew Cooper wrote:
> On 28/01/2019 14:19, Jan Beulich wrote:
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -218,6 +218,12 @@ static int apply_microcode(unsigned int
spin_unlock_irqrestore(µcode_update_lock, flags);
>
On 1/23/19 3:47 AM, Roger Pau Monne wrote:
> The current check for the present bit is wrong, since the present bit
> is located in the low part of the entry.
>
> Fixes: e8afe1124cc1 ("iommu: elide flushing for higher order map/unmap
> operations")
> Signed-off-by: Roger Pau Monné
Reviewed-by: B
From: Paul Durrant
Sent: Monday, December 17, 2018 3:22 AM
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant; Suthikulpanit, Suravee; Woods, Brian; Andrew Cooper; Wei Liu;
Roger Pau Monné
Subject: [PATCH v5 1/4] amd-iommu: add flush iommu_ops
The iommu_ops structure contains two methods for
From: Paul Durrant
Sent: Monday, December 17, 2018 3:22 AM
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant; Stefano Stabellini; Julien Grall; Andrew Cooper; George
Dunlap; Ian Jackson; Konrad Rzeszutek Wilk; Tim Deegan; Wei Liu; Suthikulpanit,
Suravee; Woods, Brian; Roger Pau Monné
Subject
On Wed, Dec 05, 2018 at 01:41:30AM -0700, Jan Beulich wrote:
> >>> On 04.12.18 at 22:35, wrote:
> > The other thing I don't get is why advertise virtualized SSBD when the
> > guest setting it does nothing? If ssbd_opt=true is set, as the code is
> > now, why even advertise it to the guest? I'd s
On Thu, Dec 06, 2018 at 06:46:51PM +, Andy Cooper wrote:
> On 06/12/2018 08:54, Jan Beulich wrote:
> On 05.12.18 at 18:05, wrote:
> >> On 05/12/2018 16:57, Jan Beulich wrote:
> >> On 03.12.18 at 17:18, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> >
On Wed, Dec 05, 2018 at 02:00:43AM -0700, Jan Beulich wrote:
> >>> On 04.12.18 at 22:47, wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_intr.c
> > +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> > @@ -665,6 +665,24 @@ int __init amd_setup_hpet_msi(struct msi_desc
> > *msi_desc)
> > retu
is passed to iommu_ops. That will
> be dealt with by a subsequent patch though.
>
> Signed-off-by: Paul Durrant
Acked-by: Brian Woods
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Thu, Nov 29, 2018 at 10:22:10AM +0100, Roger Pau Monné wrote:
> On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
> > On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
> > >On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
> > >> ... and search caches to find a sui
When using the Xen debug console and printing the IOMMU intremap tables,
it prints everything in the IVRS range regardless if it has an intr
remap or not. Add some logic to cause an entry to only be printed if
the intr remap table isn't empty.
Signed-off-by: Brian Woods
---
CC: Paul Durrant
CC:
On Mon, Dec 03, 2018 at 04:18:21PM +, Andy Cooper wrote:
> The semantics of MSR_VIRT_SPEC_CTRL are that unknown bits are write-discard
> and read as zero. Only VIRT_SPEC_CTRL.SSBD is defined at the moment.
>
> To facilitate making this per-guest, the legacy SSBD state needs context
> switchin
will plumb in guest choices. This now supercedes the older code which
> wrote to MSR_AMD64_LS_CFG once during boot.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Brian Woods
--
Brian Woods
___
Xen-devel mailing list
Xen-dev
r details.
>
> Signed-off-by: Andrew Cooper
> Parts based on an earlier patch by Brian
> Signed-off-by: Signed-off-by: Brian Woods
Needs to be:
Signed-off-by: Brian Woods
Otherwise,
Reviewed-by: Brian Woods
--
Brian Woods
___
Xen-devel m
On Mon, Dec 03, 2018 at 04:18:18PM +, Andy Cooper wrote:
> Introduce a new synthetic LEGACY_SSBD feature and set it if we find
> VIRT_SPEC_CTRL offered by our hypervisor, or if we find a working bit in an
> LS_CFG register.
>
> Signed-off-by: Andrew Cooper
Reviewd-
quivilent to MSR_SPEC_CTRL) which is provided by the
> hypervisor. This abstracts away the model-specific details of the LS_CFG
> mechanism, which allows migration safety to be retained.
>
> Signed-off-by: Andrew Cooper
Reviewd-by: Brian Woods
--
Brian Woods
fter we are done
> potentially raising faults.
>
> Reported-by: Paul Durrant
> Signed-off-by: Andrew Cooper
As far as the SVM part:
Reviewed-by: Brian Woods
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
1 - 100 of 119 matches
Mail list logo