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
nitialized.
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
een tested 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 +---
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
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 off. Y
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.
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 ne
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
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 t
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 th
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
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 -
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.
>
> L
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
>
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 f
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
>subject
uthor: 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
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
er in the boot process 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
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/as
however, nothing has been done yet and the
> cleanup path is non-trivial. It took me extra time to verify
> 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 ther
> >>
> >> 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
>
th
> 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
r ( core = 0; core < cores_per_socket; core++ )
> > +{
> > +
> > spin_lock_init(&ssbd_amd_smt_status[socket][core].lock);
> > +ssbd_amd_smt_status[socket][core].mask = 0;
> > +}
> >
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
deleted 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
-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/includ
gt; > nr_sockets either being off or not available when the code is run.
> >> > For 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
restructure things though.
Also, settings SSBD via the LS_CFG MSR is not a permanent method. Once
hardware supports using SPEC_CTRL 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&#x
[core].lock);
> ssbd_amd_smt_status[socket][core].mask = 0;
> ?
> 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
a VIRT_SPEC_CTRL)
implementation and 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
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.
j120 log. It wasn't producing a deb though, 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
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 suppor
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/includ
/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
+ printk(XENLOG_WARNING
> + "CPU%u: unclear relationship with CPU%u\n",
> + cpu, i);
> }
> }
> -else
> -{
> -cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
> -}
>
> if ( c[cpu].x86_max_cores == 1 )
> {
>
>
>
>
Side note: if cpu_core_id isn't the logical cpu, it might be worth
updating the comments in processor.h
Reviewed-by: Brian Woods
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
nce.
>
> ~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.
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
> 0x0
0 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
___
ace cf886bf535fde244 ]---
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-de
ot;undefined" to "unknown" in the print message, as there is at least
> EFER.TCE (Translation Cache Extension) defined but unknown to Xen.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Boris Ostrovsky
> Release-acked-by: Juergen Gross
> ---
> CC: Jan Beulich
INERS
> index cc1fdc013f..fab76b0af4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -144,12 +144,14 @@ F: tools/libacpi/
>
> AMD IOMMU
> M: Suravee Suthikulpanit
> +R: Brian Woods
> S: Maintained
> F: xen/drivers/passthrough/amd/
>
> AMD SVM
> 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 1006
> 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
psed_time_kernbenchhalf.pdf
elapsed_time_kernbenchquad.pdf
elapsed_time_pi03.pdf
elapsed_time_pi24.pdf
--
Brian Woods
elapsed_time_kernbenchquad.pdf
Description: Adobe PDF document
elapsed_time_kernbenchhalf.pdf
Description: Adobe PDF document
elapsed_time_pi03
If available, enable the pause filtering threshold feature. See the
previous commit for more information.
Signed-off-by: Brian Woods
---
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/x86/hvm/svm/svm.c b/xen/arch
thout pause filtering threshold, the change, from 3000 to
4000 for the count, should not negatively effect system performance.
Signed-off-by: Brian Woods
---
xen/include/asm-x86/hvm/svm/svm.h | 5 -
xen/include/asm-x86/hvm/svm/vmcb.h | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
keeps 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
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/nestedsvm.c| 66 +
xen/arch/x86/hvm/svm/svm.c | 6 +++
xen/arch/x86/hvm/svm/vmcb.c
abled(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
___
X
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
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/nestedsvm.c| 66 +
xen/arch/x86/hvm/svm/svm.c | 6 +++
xen/arch/x86/hvm/svm/vmcb.c
if and
going in and out a function but 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.
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
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/svm.c | 71 +
xen/arch/x86/hvm/svm/vmcb.c | 17 ---
2 files changed, 71 insertions(+), 17
to keep it consistent
within the file. For things like if () {\n,} \{, which are
inconsistent, I always use if () \n \{. Should I only be using boolean?
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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
---
xen/arch/x86/hvm/svm/nestedsvm.c
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
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/nestedsvm.c | 10 --
xen/arch/x86/hvm/svm/
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/svm.c | 69 +
xen/arch/x86/hvm/svm/vmcb.c | 17 ---
2 files changed, 69 insertions(+), 17
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
ne. Oddly
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 mail
ng 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-d
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
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/svm.c | 29
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
---
xen/arch/x86/hvm/svm/vmcb.c | 5 +++--
1 file changed, 3 insertions(
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
76 matches
Mail list logo
