On Wed, Jul 22, 2020 at 09:47:43AM -0700, Stefano Stabellini wrote:
> On Tue, 21 Jul 2020, Brian Woods wrote:
> > Modify the smmu driver so that it uses the iommu_fwspec helper
> > functions. This means both ARM IOMMU drivers will both use the
> > iommu_fwspec helper funct
Finally had time to do a v2. Changes are in each patch.
Brian Woods (2):
arm,smmu: switch to using iommu_fwspec functions
arm,smmu: add support for generic DT bindings
xen/drivers/passthrough/arm/smmu.c| 147 --
xen/drivers/passthrough/device_tree.c
Modify the smmu driver so that it uses the iommu_fwspec helper
functions. This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions.
Signed-off-by: Brian Woods
---
Interested in if combining the legacy and generic bindings paths are
worth or if Xen plans to depreicate
Restructure some of the code and add supporting functions for adding
generic device tree (DT) binding support. This will allow for using
current Linux device trees with just modifying the chosen field to
enable Xen.
Signed-off-by: Brian Woods
---
Just realized that I'm fairly sure I need to do
.
Signed-off-by: Brian Woods
---
RFC especially on:
- Checks for the: arm_smmu_dt_add_device* and arm_smmu_dt_xlate*
functions.
xen/drivers/passthrough/arm/smmu.c| 118 +-
xen/drivers/passthrough/device_tree.c | 17 +
2 files changed, 87 insertions
with device passthrough on a Xilinx
ZCU102 with passing the on board ethernet to a guest via the SMMU.
Brian Woods (2):
arm,smmu: add support for iommu_fwspec functions
smmu: add support for generic DT bindings
xen/drivers/passthrough/arm/smmu.c| 156 +-
xen/drivers
Modify the smmu driver so that it uses the iommu_fwspec helper
functions. This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions, making enabling generic device tree
bindings in the SMMU driver much cleaner.
Signed-off-by: Brian Woods
---
RFC especially wanted
On Thu, Oct 17, 2019 at 10:49:15PM +0100, Julien Grall wrote:
> On Thu, 17 Oct 2019 at 22:20, Brian Woods wrote:
> >
> > On Thu, Oct 17, 2019 at 09:34:51PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > As a user such message would likely put me o
On Thu, Oct 17, 2019 at 09:34:51PM +0100, Julien Grall wrote:
> Hi,
>
> On Thu, 17 Oct 2019 at 21:08, Brian Woods wrote:
> >
> > It's possible for a misconfigured device tree to cause Xen to crash when
> > there are overlapping addresses in the memory modules. Add
It's possible for a misconfigured device tree to cause Xen to crash when
there are overlapping addresses in the memory modules. Add a warning
when printing the addresses to let the user know there's a possible
issue.
Signed-off-by: Brian Woods
---
v1 -> v2
- removed nested l
On Thu, Oct 17, 2019 at 10:20:11AM +0100, Julien Grall wrote:
> Hi,
>
> Sorry for the late answer.
>
> On 11/10/2019 20:07, Brian Woods wrote:
> >Which is why I wanted to put it where it was in the patch. Where the
> >user would see the warning after the information
On Fri, Oct 11, 2019 at 07:17:29PM +0100, Julien Grall wrote:
> Hi,
>
> On 10/11/19 7:06 PM, Brian Woods wrote:
> >On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
> >For that, you'd need to either check the start and end of the added
> >module or the s
On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
> Hi,
>
> Please at least remove the signature in the e-mail you reply to. The best
> would be to trim the e-mail and answer right below the specific paragraph.
>
> >
> >To make sure the module is going to get added, you'd need to do
On Thu, Oct 10, 2019 at 04:39:07PM +0100, Julien Grall wrote:
> Hi Brian,
>
> Thank you for the patch.
>
> On 10/9/19 8:47 PM, Brian Woods wrote:
> >It's possible for a misconfigured device tree to cause Xen to crash when
> >there are overlapping addresses in the mem
It's possible for a misconfigured device tree to cause Xen to crash when
there are overlapping addresses in the memory modules. Add a warning
when printing the addresses to let the user know there's a possible
issue when DEBUG is enabled.
Signed-off-by: Brian Woods
---
sample output:
...
(XEN
On Fri, Oct 04, 2019 at 10:49:28AM +0100, Julien Grall wrote:
> Hi Brian,
>
> On 04/10/2019 01:25, Brian Woods wrote:
> >
> >In the log, there's:
> >(XEN) MODULE[0]: 0140 - 015328f1 Xen
> >(XEN) MODULE[1]: 076d2000 - 076dc
On Thu, Oct 03, 2019 at 10:20:36PM +0100, Julien Grall wrote:
> Hi Brian,
>
> On 10/3/19 9:24 PM, Brian Woods wrote:
> >On Thu, Oct 03, 2019 at 07:23:23PM +, Julien Grall wrote:
> >There's a WARN_ON() between the two debug printks calls I shared above.
>
> Lookin
On Thu, Oct 03, 2019 at 07:23:23PM +, Julien Grall wrote:
> Hi,
>
> On 03/10/2019 19:15, Brian Woods wrote:
> > On Thu, Oct 03, 2019 at 06:08:45PM +0100, Julien Grall wrote:
> > (XEN) BW_DEBUG: .6 count_info=0x
> > (XEN) Domain heap initial
On Thu, Oct 03, 2019 at 06:08:45PM +0100, Julien Grall wrote:
> Hi,
>
> On 03/10/2019 00:20, Brian Woods wrote:
> >On Wed, Oct 02, 2019 at 02:22:49PM -0700, Brian Woods wrote:
> >>That's odd. I know I copied your and Stefano's email addresses from the
> >>M
On Wed, Oct 02, 2019 at 02:22:49PM -0700, Brian Woods wrote:
> On Wed, Oct 02, 2019 at 08:59:28PM +0100, Julien Grall wrote:
> > Hi,
> >
> > On 10/2/19 7:56 PM, Brian Woods wrote:
> >
> > Hmmm, the first e-mail didn't land in my inbox directly (I have a filter
On Wed, Oct 02, 2019 at 08:59:28PM +0100, Julien Grall wrote:
> Hi,
>
> On 10/2/19 7:56 PM, Brian Woods wrote:
> >On 10/2/19 5:52 PM, Julien Grall wrote:
> >>On 10/2/19 1:32 AM, Brian Woods wrote:
> >>>Hello,
> >>
> >>Hi Brian,
> >&g
On 10/2/19 5:52 PM, Julien Grall wrote:
>On 10/2/19 1:32 AM, Brian Woods wrote:
>>Hello,
>
>Hi Brian,
>
>Thank you for report.
>
>I guess this Arm specific, right? If so, please try to CC
>the relevant maintainers and possibly add "arm" in the
>subj
: Julien Grall
Date: Tue Dec 18 13:07:39 2018 +
xen/arm: Stop relocating Xen
was what was causing it to fail when it was loaded to that certain
address.
I've attached the logs from a build from staging (about a week or so
ago) with both a passing and failing address.
--
Brian Woods
PMU
oth threads share the same MSR. Otherwise, a core just
> > needs to write to the LS_CFG MSR. For more information see:
> > https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreB
> >
> > ypassDisable_Whitepaper_final.pdf
> >
> > Signed-off-by:
-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c| 13 +--
xen/arch/x86/smpboot.c| 3 +
xen/arch/x86/spec_ctrl.c | 172 +-
xen/include/asm
ss due to a v1 change, use
nr_sockets
- various smaller changes/cleanups from Jan's feedback
Brian Woods (2):
x86/spec-ctrl: add AMD SSBD LS_CFG in init print
x86/spec-ctrl: add support for modifying SSBD via LS_CFG MSR
xen/arch/x86/cpu/amd.c| 15 ++--
xen/arch/x86/smp
Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
enable it to pass the status to the initial spec-ctrl print_details at
boot.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c | 12 +---
xen/arch/x86/spec_ctrl.c| 10 --
xen/include/asm-x86
> that nothing bad would happen from going that path despite
> nothing having been done before. It is far more clear to the
> reader imo if there is just "return" here.
Well, it's just a difference of opinion at this point. I'll change it.
> >>
> >> Signed-off-by: Jan Beulich
> >
> > I have confirmed it with a senior hardware engineer and using vmload in
> > this fashion is safe and recommended for performance. As far as using
> > vmload with PV.
> >
> > Acked-by: Brian Woods
&g
t; functions having more than 6 parameters.
>
> Signed-off-by: Jan Beulich
I have confirmed it with a senior hardware engineer and using vmload in
this fashion is safe and recommended for performance. As far as using
vmload with PV.
Acked-by: Brian Woods
--
Brian Woods
_
> > +
> > spin_lock_init(_amd_smt_status[socket][core].lock);
> > +ssbd_amd_smt_status[socket][core].mask = 0;
> > +}
> > +}
> > +}
> > +break;
> >
On Thu, Aug 09, 2018 at 02:42:13PM -0500, Brian Woods wrote:
> @@ -237,8 +247,8 @@ static void __init print_details(enum ind_thunk thunk,
> uint64_t caps)
> - !boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG)? "" :
> - (opt_ssbd && ssbd_amd_ls_cfg_ma
ted ssbd_amd_ls_cfg_set_init due to ^ and it happening later
in the boot
- various smaller cleanups
Brian Woods (2):
x86/spec-ctrl: add AMD SSBD LS_CFG in init print
x86/spec-ctrl: add support for modifying SSBD VIA LS_CFG MSR
xen/arch/x86/cpu/amd.c| 12 ++-
xen/arch/x86/setu
-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c | 7 +-
xen/arch/x86/smpboot.c | 3 +
xen/arch/x86/spec_ctrl.c| 174 +++-
xen/include/asm-x86
Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
enable it to pass the status to the initial spec-ctrl print_details at
boot.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c| 13 ++---
xen/arch/x86/spec_ctrl.c | 9 +++--
xen/include/asm
r Family 17h which the patches are for, there's a max of two sockets.
> >>
> >> I've implied that from how you wrote the patches, but such hard coding
> >> will only make for more code churn later on. Try to be as generic as
> >> possible.
>
for it, it won't be needed. For
multisocket systems, there should only be 2 sockets. I agree with
making things generic, but this early in the boot there's limited
information.
> >> Btw - why the xen_ prefix for the variable?
> >
> > See the first reply, but basically it's
t; ?
> Labels indented by at least one blank please.
Noted about the above.
> Btw - why the xen_ prefix for the variable?
See the first reply, but basically it's for if Xen has SSBD turned on
or not via using the LS_CFG MSR.
> Pointless "return" at end of function.
>
>
d he mentioned something about ALTERNATIVE C funcs
which would allow to allow HVM guests to be able control SSBD. In that
case having a synthetic feature flag is useful for helping to
differiate between SSBD via the LS_CFG MSR vs SPEC_CTRL in the future.
--
Brian Woods
___
On Tue, Jul 31, 2018 at 04:44:57AM -0600, Jan Beulich wrote:
> Whether these additions fit the purpose can only be told when
> seeing their use. Please fold this into the patch using these.
>
> Jan
I was trying to split up patch 3 but I'll combine 2 and 3.
--
after
doing cleans and distcleans it still wasn't producing a new debball.
I'm guessing it was transient because when I tried to reproduce it
again today, it was successful, repeatedly. Either way, sorry about
this. Next time this happens I'll make sure to pull a fresh copy to
double check rather
for guests via the VIRT_SPEC_CTRL.
Note: these should be applied after Jan's patch:
x86/AMD: distinguish compute units from hyper-threads
Brian Woods (3):
x86/spec-ctrl: add AMD SSBD LS_CFG in init print
x86/spec-ctrl: Add defines and variables for AMD SSBD support
x86/spec-ctrl: Add support
In preparation for adding switchable SSBD, add some defines and
variables.
Signed-off-by: Brian Woods
---
xen/arch/x86/spec_ctrl.c| 10 ++
xen/include/asm-x86/spec_ctrl.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86
Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
enable it to pass the status to the initial spec-ctrl print_details at
boot.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c| 13 ++---
xen/arch/x86/spec_ctrl.c | 9 +++--
xen/include/asm
/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c | 10 +--
xen/arch/x86/setup.c | 2 +
xen/arch/x86/smpboot.c | 3 +
xen/arch/x86/spec_ctrl.c | 201
E_ID &&
> + c[i].cpu_core_id != XEN_INVALID_CORE_ID )
> +{
> +if ( c[cpu].cpu_core_id == c[i].cpu_core_id )
> +link_thread_siblings(cpu, i);
> +}
> +else
> +printk(XENLOG_WARNIN
>
> ~Andrew
I'll take a look into updating it for AMD related processors then. I
will talk with some people internally who did the work for Linux and
see what needs to be done etc.
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Wed, Jun 20, 2018 at 12:20:21PM -0500, Brian Woods wrote:
> On Wed, Jun 20, 2018 at 08:34:13AM +0200, Juergen Gross wrote:
> Juergen,
>
> It works for Dom0. You see a lot of messages that are like:
> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR c0011020 from
>
8000 to 0x02068400
(XEN) emul-priv-op.c:1166:d0v0 Domain attempted WRMSR c0011020 from
0x02068000 to 0x02068400
But it boots up. I'll test a DomU with a newer kernel after I get back
from lunch.
--
Brian Woods
___
Xen-d
]---
With nospec_store_bypass_disable, it boots fine etc. It seems to works
fine (at least Dom0 can boot).
Linux Kernel -> 4.17.2
Xen -> current HEAD on master
Is this a known or expected problem?
--
Brian Woods
___
Xen-devel mailing list
Xen
Juergen Gross <jgr...@suse.com>
> ---
> CC: Jan Beulich <jbeul...@suse.com>
> CC: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
> CC: Brian Woods <brian.wo...@amd.com>
>
> Arguably, this wants backporting to the stable trees, so should be consid
it a/MAINTAINERS b/MAINTAINERS
> index cc1fdc013f..fab76b0af4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -144,12 +144,14 @@ F: tools/libacpi/
>
> AMD IOMMU
> M: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
> +R: Brian Woods <brian.wo...@
> xen/include/asm-x86/hvm/svm/vmcb.h | 52 ++-
> xen/include/asm-x86/hvm/vlapic.h| 4 +
> xen/include/asm-x86/msr-index.h | 1 +
> 14 files changed, 831 insertions(+), 30 deletions(-)
> create mode 100644 xen/arch/x86/hvm/svm/avic.c
> create mode 100644 xen/include/
ots
> every other month: but this is not ideal for some.
>
> To do this, please
> * Raise your hands on whether you or your org would want to participate
\o/
> * Provide your timezone
CT
> * Provide a UTC time range when you can attend
15:00-23:00
> Your sincerely,
> Lars
If available, enable the pause filtering threshold feature. See the
previous commit for more information.
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/arch/x86/hvm/svm/svm.c | 1 +
xen/arch/x86/hvm/svm/vmcb.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/xen/arch/x
pause filtering threshold, the change, from 3000 to
4000 for the count, should not negatively effect system performance.
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/include/asm-x86/hvm/svm/svm.h | 5 -
xen/include/asm-x86/hvm/svm/vmcb.h | 3 ++-
2 files changed, 6 insertions
the guset from getting intercepted by the hypervisor. See AMD
APM vol 2 section 15.14.4 for more details.
In reply to this will be an email with graphs showing some benchmark
results of why the values of the counter and threshold were picked.
Brian Woods (2):
x86/svm: add support for pause
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/arch/x86/hvm/svm/nestedsvm.c| 66 +
xen/arch/x86/h
(v->domain) || !(v->arch.hvm_vcpu.guest_efer &
> EFER_SVME));
>
> (which wasn't the first choice for either of you ;-))
>
> -boris
I'll change it and send out a new version then.
--
Brian Woods
___
Xen-devel mailin
I've seen patch 1 and 3 are in but this one isn't. Any status on it?
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/arch/x86/hvm/svm/nestedsvm.c| 66 +
xen/arch/x86/h
you add a small divergence in the
codepath. If this was a long computer/IO intense function, I'd
completely agree but this is two very simple checks.
I'll change it though, since it'll be easier than going back and forth
about a minor detail.
--
Brian Woods
__
If Andy wants to use his version of this, that's fine also. This is
just a newer version based on Jan's input.
v1 -> v2
Got rid of "== X"s
Added an assert and got rid of a check in an if
--
Brian Woods
___
Xen-devel mailing l
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/arch/x86/hvm/svm/svm.c | 71 +
xen/arch/x86/hvm/svm
ge with my
version but to be honest, I don't think it matters either way. I like
the locality of mine better, but I'm perfectly fine with either.
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
There are places where the GIF value is checked. A guest with VGIF
enabled can change the GIF value without the host being involved,
therefore it needs to check the GIF value in the VMCB rather the one in
the nestedsvm struct.
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/ar
Corrects some EFER.SVME checks in intercepts. See AMD APM vol2 section
15.4 for more details. VMMCALL isn't checked due to guests needing it
to boot.
Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/arch/x86/hvm/svm
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/arch/x86/hvm/svm/svm.c | 69 +
xen/arch/x86/hvm/svm
This is a small series of SVM cleanup patches. The first patch is
correcting a couple of checks relating to VGIF. The other two are
ensuring that nested SVM functionality is emulated/setup more
correctly.
Brian Woods (3):
x86/svm: update VGIF support
x86/svm: add EFER SVME support for VGIF
ly
enough you can at least get a system booted on 17h family systems even
if it's fragile but 15h just fails to even boot. Not sure how it even
worked when I tested previous patches on the 15h system.
--
Brian Woods
___
Xen-devel mailing list
Xen-de
correctly. The joys of being under the weather and
forgetting all your mental notes. I'll try to send out a v2 of this
patch today with the corrections.
Thank you for your input.
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists
Checks the hvm EFER.SVME bit to make sure the EFER.SVME bit it high
before allowing nested SVM intercepts to be handled successfully. On
SVME being low, it generates a #UD as per the AMD APM vol2 15.4.
Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Brian Woods <
Add a nestedhvm_enable() check to the existing checks for setting the
virtual GIF and virtual VMLOAD/VMSAVE features. If it isn't a nestedhvm
guest, do not enable the features in the VMCB.
Signed-off-by: Brian Woods <brian.wo...@amd.com>
---
xen/arch/x86/hvm/svm/vmcb.c | 5 +++--
1 file c
This is small patch series which does some basic maintenance work in the
SVM section.
1. Add support for checking the SVME bit before doing nested SVM
operations
2. Add support for checking if nestedhvm is enabled before enabling
nested SVM features in the VMCB.
Brian Woods (2):
x86
74 matches
Mail list logo
