I will not be looking at AMD related Xen code now.
So, removing myself.
Signed-off-by: Aravind Gopalakrishnan
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 932b05c..7aacfd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -107,14 +107,12 @@ F
odify those bits.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Aravind Gopalakrishnan
---
xen/arch/x86/hvm/svm/vpmu.c | 49 +++--
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
On 5/26/2015 1:09 PM, Boris Ostrovsky wrote:
On 05/26/2015 12:24 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, wrote:
@@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
}
}
-static void amd_vpmu_load(struct vcpu *v)
+static int amd_vpmu_load(struct vcpu *v, bool_t f
ng avoided
here. All that's required is sensible guest side data for the clflush
line size.
Signed-off-by: Jan Beulich
Reviewed-by: Aravind Gopalakrishnan
Thanks,
-Aravind.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 3/12/2015 6:54 AM, Jan Beulich wrote:
* amd_ucode cleanups, verify patch size(enhancement) (mostly in master
except one patch)
Which one?
This is in reference to the patches to microcode_amd and it's all 'done'
in 4.5 itself.
I think when we were tracking this, commit 8b24b07e was not in
On 9/4/2015 7:08 AM, Roger Pau Monne wrote:
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
Cc: Suravee Suthikulpanit
Cc: Aravind Gopalakrishnan
---
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/drivers/passthrough/amd/iommu_guest.c | 3 ++-
1 file changed, 2 insertions
y the BIOS
A linux version of the patch has already made it into tip-
http://marc.info/?l=linux-kernel&m=143703405627170
Signed-off-by: Aravind Gopalakrishnan
---
Changes from V1 (per Andrew)
- use commit text from linux patch
- include details about how 'final_levels' are obtaines i
On 8/3/2015 12:22 PM, Boris Ostrovsky wrote:
On 08/03/2015 12:35 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The
On 8/3/2015 1:18 PM, Boris Ostrovsky wrote:
On 08/03/2015 01:52 PM, Aravind Gopalakrishnan wrote:
On 8/3/2015 12:22 PM, Boris Ostrovsky wrote:
On 08/03/2015 12:35 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels
On 8/3/2015 2:00 PM, Boris Ostrovsky wrote:
On 08/03/2015 02:42 PM, Aravind Gopalakrishnan wrote:
Ah. I see what you mean.
I can think of two ways around this-
a. I can move the check_final_patch_levels() call to
apply_microcode(). That way, our initial checks in microcode_fits()
would have
y the BIOS
A linux version of the patch has already made it into tip-
http://marc.info/?l=linux-kernel&m=143703405627170
Signed-off-by: Aravind Gopalakrishnan
Reviewed-by: Andrew Cooper
---
Changes from V2 (per Boris)
- introduce family check as it's theoritically possible to have
On 8/11/2015 9:53 AM, Jan Beulich wrote:
On 03.08.15 at 21:34, wrote:
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -347,6 +347,43 @@ static int container_fast_forward(const void *data, size_t
size_left, size_t *of
return 0;
}
+/*
+ * The 'final_levels' o
On 8/11/2015 10:17 AM, Andrew Cooper wrote:
+0x0198,
+0x019f,
+0x01af
+};
+
+static bool_t check_final_patch_levels(int cpu)
unsigned int
I can change this too, but- Any specific reason for this?
The other sanity checker or verification functions like
verify_patch_siz
On 8/11/2015 10:32 AM, Jan Beulich wrote:
+static bool_t check_final_patch_levels(int cpu)
unsigned int
I can change this too, but- Any specific reason for this?
The other sanity checker or verification functions like
verify_patch_size() or microcode_fits() return a bool_t too..
"int cpu" is
of pr_debug()
- correct unsigned int usage
Aravind Gopalakrishnan (2):
x86/microcode: Cleanup int type usage for cpu numbers
x86, amd_ucode: Skip microcode updates for final levels
xen/arch/x86/microcode.c| 6 ++---
xen/arch/x86/microcode_amd.c| 57 ++
y the BIOS
A linux version of the patch has already made it into tip-
http://marc.info/?l=linux-kernel&m=143703405627170
Signed-off-by: Aravind Gopalakrishnan
Reviewed-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
---
xen/arch/x86/microcode_amd.c | 45 +++
CPU numbers can't be negative. Fixing the microcode*
files to properly use unsigned type in this patch.
No functional change is introduced.
Signed-off-by: Aravind Gopalakrishnan
---
xen/arch/x86/microcode.c| 6 +++---
xen/arch/x86/microcode_amd.c| 12 +++-
xen/arc
On 8/12/2015 4:38 AM, Jan Beulich wrote:
On 11.08.15 at 21:11, wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The 'final_levels' of patch ids have
cpu_request_microcode()'s first loop, and also check the types of
skipped blocks in container_fast_forward().
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Reviewed-by: Aravind Gopalakrishnan
___
Xen-devel mailing list
Xen-devel@lists.xe
On 10/20/2015 5:41 AM, Jan Beulich wrote:
... to tell them apart by their names even without further context.
Signed-off-by: Jan Beulich
Reviewed-by: Aravind Gopalakrishnan
Thanks,
-Aravind.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On 10/22/2015 10:44 AM, Boris Ostrovsky wrote:
On 10/22/2015 10:17 AM, Jan Beulich wrote:
On 28.09.15 at 09:13, wrote:
The existing hvm_set_guest_tsc_fixed() and hvm_get_guest_tsc_fixed()
calculate the guest TSC by adding the TSC offset to the host TSC. When
the TSC scaling is enabled, the hos
already applied by
the BIOS.
A linux version of the patch has already made it into tip-
http://marc.info/?l=linux-kernel&m=143703405627170
Signed-off-by: Aravind Gopalakrishnan
---
xen/arch/x86/microcode_amd.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a
On 7/30/2015 12:01 PM, Andrew Cooper wrote:
On 30/07/15 17:23, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that the microcode versions
that it comes up with should not be updated by the microcode driver.
Otherwise, system hangs are known to occur.
In this patch, we
On 7/31/2015 3:48 PM, Andrew Cooper wrote:
So, the patch id values have only been obtained empirically.
The Linux patch provides the bug reference for
this:https://bugzilla.suse.com/show_bug.cgi?id=913996
(It's a fairly long thread but the gist of it is that people
predominantly seem to be expe
24 matches
Mail list logo
