[Xen-devel] [PATCH] MAINTAINERS: remove myself from SVM and AMD IOMMU

2019-08-15 Thread Woods, Brian
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:

Re: [Xen-devel] [PATCH v5 00/10] AMD IOMMU: further improvements

2019-08-15 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH] x86/AMD-Vi: Fold exit paths of {enable, disable}_iommu()

2019-08-12 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v5 02/10] AMD/IOMMU: drop stray "else"

2019-08-08 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v5 01/10] AMD/IOMMU: miscellaneous DTE handling adjustments

2019-08-06 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v4 12/12] AMD/IOMMU: miscellaneous DTE handling adjustments

2019-08-06 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH] passthrough/amd: Drop "IOMMU not found" message

2019-08-06 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v4 11/12] AMD/IOMMU: don't needlessly log headers when dumping IRTs

2019-07-30 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v4 05/12] AMD/IOMMU: introduce 128-bit IRTE non-guest-APIC IRTE format

2019-07-30 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v4 01/12] AMD/IOMMU: use bit field for extended feature register

2019-07-30 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v4 10/12] AMD/IOMMU: correct IRTE updating

2019-07-25 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v4 06/13] x86/IOMMU: don't restrict IRQ affinities to online CPUs

2019-07-24 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 1/2] x86/mm: Clean IOMMU flags from p2m-pt code

2019-07-24 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 2/2] passthrough/amd: Clean iommu_hap_pt_share enabled code

2019-07-24 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 14/14] AMD/IOMMU: process softirqs while dumping IRTs

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 12/14] AMD/IOMMU: enable x2APIC mode when available

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 11/14] AMD/IOMMU: adjust setup of internal interrupt for x2APIC mode

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 10/14] AMD/IOMMU: allow enabling with IRQ not yet set up

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 09/14] AMD/IOMMU: split amd_iommu_init_one()

2019-07-19 Thread Woods, Brian
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().

Re: [Xen-devel] [PATCH v3 07/14] AMD/IOMMU: pass IOMMU to {get, free, update}_intremap_entry()

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 06/14] AMD/IOMMU: pass IOMMU to amd_iommu_alloc_intremap_table()

2019-07-19 Thread Woods, Brian
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.

Re: [Xen-devel] [PATCH v3 05/14] AMD/IOMMU: pass IOMMU to iterate_ivrs_entries() callback

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 04/14] AMD/IOMMU: use bit field for IRTE

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 03/14] AMD/IOMMU: use bit field for control register

2019-07-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 01/14] AMD/IOMMU: free more memory when cleaning up after error

2019-07-19 Thread Woods, Brian
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 >

Re: [Xen-devel] [PATCH v2 1/4] iommu / x86: move call to scan_pci_devices() out of vendor code

2019-07-16 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v2 01/10] AMD/IOMMU: restrict feature logging

2019-07-01 Thread Woods, Brian
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 > --- >

Re: [Xen-devel] [PATCH] x86/svm: Drop svm_vm{load,save}() helpers

2019-06-28 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v2] AMD/IOMMU: don't "add" IOMMUs

2019-06-26 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 3/5] x86/AMD: make C-state handling independent of Dom0

2019-06-21 Thread Woods, Brian
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:

Re: [Xen-devel] [PATCH 3/5] x86/AMD: make C-state handling independent of Dom0

2019-06-21 Thread Woods, Brian
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:

Re: [Xen-devel] [PATCH] AMD/IOMMU: revert "amd/iommu: assign iommu devices to Xen"

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH] x86/svm: Fix svm_vmcb_dump() when used in current context

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/2] x86: init_hypercall_page() cleanup

2019-06-19 Thread Woods, Brian
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 >

Re: [Xen-devel] [PATCH v3 13/13] print: introduce a format specifier for pci_sbdf_t

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 12/13] pci: switch pci_conf_write32 to use pci_sbdf_t

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 09/13] pci: switch pci_conf_read32 to use pci_sbdf_t

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 08/13] pci: switch pci_conf_read16 to use pci_sbdf_t

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 07/13] pci: switch pci_conf_read8 to use pci_sbdf_t

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 3/5] x86/AMD: make C-state handling independent of Dom0

2019-06-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH] AMD/IOMMU: initialize IRQ tasklet only once

2019-06-18 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 3/5] x86/AMD: make C-state handling independent of Dom0

2019-06-18 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

2019-06-17 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/9] AMD/IOMMU: use bit field for extended feature register

2019-06-17 Thread Woods, Brian
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_

Re: [Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

2019-05-30 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH] x86/svm: Drop support for AMD's Lightweight Profiling

2019-05-20 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

2019-05-09 Thread Woods, Brian
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

Re: [Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

2019-05-06 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH] AMD/IOMMU: disable previously enabled IOMMUs upon init failure

2019-04-11 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts

2019-04-10 Thread Woods, Brian
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. > >

Re: [Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

2019-04-08 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 7/7] x86/IOMMU: initialize iommu_ops in vendor-independent code

2019-04-05 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 4/7] x86/IOMMU: introduce init-ops structure

2019-04-05 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 3/7] x86/ACPI: also parse AMD IOMMU tables early

2019-04-05 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-03-28 Thread Woods, Brian
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

[Xen-devel] [PATCH v2 1/3] mwait-idle: add support for using halt

2019-03-28 Thread Woods, Brian
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

[Xen-devel] [PATCH v2 3/3] mwait-idle: add enablement for AMD Naples and Rome

2019-03-28 Thread Woods, Brian
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

[Xen-devel] [PATCH v2 2/3] mwait-idle: add support for AMD processors

2019-03-28 Thread Woods, Brian
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

[Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

2019-03-28 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-03-28 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-03-27 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-03-26 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v6 00/12] improve late microcode loading

2019-03-19 Thread Woods, Brian
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 >>

Re: [Xen-devel] [PATCH v6 00/12] improve late microcode loading

2019-03-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-03-19 Thread Woods, Brian
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 { >>

Re: [Xen-devel] [PATCH 3/3] mwait-idle: add enablement for AMD Naples and Rome

2019-03-19 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 3/3] mwait-idle: add enablement for AMD Naples and Rome

2019-03-14 Thread Woods, Brian
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 >>

Re: [Xen-devel] [PATCH 2/3] mwait-idle: add support for AMD processors

2019-03-14 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-03-14 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-03-11 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-02-27 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 0/3] mwait support for AMD processors

2019-02-27 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 0/3] mwait support for AMD processors

2019-02-26 Thread Woods, Brian
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 >>

Re: [Xen-devel] [PATCH 0/3] mwait support for AMD processors

2019-02-26 Thread Woods, Brian
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

[Xen-devel] [PATCH 2/3] mwait-idle: add support for AMD processors

2019-02-25 Thread Woods, Brian
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

[Xen-devel] [PATCH 3/3] mwait-idle: add enablement for AMD Naples and Rome

2019-02-25 Thread Woods, Brian
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

[Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt

2019-02-25 Thread Woods, Brian
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 +-

[Xen-devel] [PATCH 0/3] mwait support for AMD processors

2019-02-25 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 1/2] amd-iommu: use a bitfield for PTE/PDE

2019-02-13 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 2/2] amd-iommu: use a bitfield for DTE

2019-02-12 Thread Woods, Brian
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 >

Re: [Xen-devel] [PATCH 1/2] amd-iommu: use a bitfield for PTE/PDE

2019-02-12 Thread Woods, Brian
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 >

Re: [Xen-devel] [PATCH for-4.12 v4 2/3] x86/svm: Drop enum instruction_index and simplify svm_get_insn_len()

2019-01-31 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3 1/3] x86/svm: Remove list functionality from __get_instruction_length_* infrastructure

2019-01-31 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 03/14] AMD/IOMMU: Fix multiple reference counting errors

2019-01-31 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3] x86/AMD: flush TLB after ucode update

2019-01-28 Thread Woods, Brian
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); >

Re: [Xen-devel] [PATCH for-4.12] amd/iommu: fix present bit checking when clearing PTE

2019-01-24 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v5 1/4] amd-iommu: add flush iommu_ops

2018-12-20 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v5 3/4] iommu: elide flushing for higher order map/unmap operations

2018-12-20 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 8/9] x86/amd: Virtualise MSR_VIRT_SPEC_CTRL for guests

2018-12-06 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 6/9] x86/amd: Allocate resources to cope with LS_CFG being per-core on Fam17h

2018-12-06 Thread Woods, Brian
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 > >

Re: [Xen-devel] [PATCH] AMD IOMMU: fix debug console IOMMU intremap output

2018-12-05 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v3] amd-iommu: remove page merging code

2018-12-04 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH v4 2/6] microcode: save all microcodes which pass sanity check

2018-12-04 Thread Woods, Brian
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

[Xen-devel] [PATCH] AMD IOMMU: fix debug console IOMMU intremap output

2018-12-04 Thread Woods, Brian
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:

Re: [Xen-devel] [PATCH 8/9] x86/amd: Virtualise MSR_VIRT_SPEC_CTRL for guests

2018-12-04 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 7/9] x86/amd: Support context switching legacy SSBD interface

2018-12-04 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 6/9] x86/amd: Allocate resources to cope with LS_CFG being per-core on Fam17h

2018-12-04 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 5/9] x86/amd: Probe for legacy SSBD interfaces on boot

2018-12-04 Thread Woods, Brian
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-

Re: [Xen-devel] [PATCH 4/9] x86/amd: Introduce CPUID/MSR definitions for per-vcpu SSBD support

2018-12-04 Thread Woods, Brian
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

Re: [Xen-devel] [PATCH 2/2] x86/hvm: Corrections to RDTSCP intercept handling

2018-11-30 Thread Woods, Brian
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   2   >