On Mon, Aug 05, 2019 at 10:43:16AM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> @@ -234,6 +267,35 @@ bool microcode_update_cache(struct microcode_patch
>> *patch)
>> }
>>
>> /*
>> + * Wait for a condition to be met with
On Mon, Aug 05, 2019 at 09:38:00AM +, Jan Beulich wrote:
>On 05.08.2019 09:36, Chao Gao wrote:
>> On Fri, Aug 02, 2019 at 03:40:55PM +, Jan Beulich wrote:
>>> On 01.08.2019 12:22, Chao Gao wrote:
>>>> --- a/xen/arch/x86/microcode.c
>>>> +++
On Mon, Aug 05, 2019 at 09:27:58AM +, Jan Beulich wrote:
>On 05.08.2019 07:58, Chao Gao wrote:
>> On Fri, Aug 02, 2019 at 01:29:14PM +, Jan Beulich wrote:
>>> On 01.08.2019 12:22, Chao Gao wrote:
>>>> --- a/xen/arch/x86/microcode_intel.c
>>>
On Fri, Aug 02, 2019 at 03:40:55PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> --- a/xen/arch/x86/microcode.c
>> +++ b/xen/arch/x86/microcode.c
>> @@ -189,12 +189,20 @@ static DEFINE_SPINLOCK(microcode_mutex);
>>
>> DEFINE_PER_
On Fri, Aug 02, 2019 at 02:46:58PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> +bool microcode_update_cache(struct microcode_patch *patch)
>> +{
>> +
>> +ASSERT(spin_is_locked(µcode_mutex));
>> +
>> +if ( !microcode_cach
On Fri, Aug 02, 2019 at 03:21:55PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> --- a/xen/arch/x86/microcode.c
>> +++ b/xen/arch/x86/microcode.c
>> @@ -277,6 +277,9 @@ static long do_microcode_update(void *_info)
>> if ( error )
>&
On Fri, Aug 02, 2019 at 01:29:14PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> --- a/xen/arch/x86/microcode_intel.c
>> +++ b/xen/arch/x86/microcode_intel.c
>> @@ -134,14 +134,35 @@ static int collect_cpu_info(unsigned int cpu_num,
>>
lot and only a single ucode is
cached. a single invocation of ->apply_microcode() would load the cache
and make microcode updated.
Signed-off-by: Chao Gao
---
changes in v8:
- new
- separated from the following patch
---
xen/arch/x86/microcode.c|
of logical threads.
3.get/put_cpu_bitmaps() prevents the concurrency of CPU-hotplug and
late microcode update.
Note that printk in apply_microcode() and svm_host_osvm_init() (for AMD
only) are still processed sequentially.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
Changes in v7
apply_microcode()'s always loading the cached ucode patch forces
a patch to be stored before being loading. Make apply_microcode()
accept a patch pointer to remove the limitation so that a patch
can be stored after a successful loading.
Signed-off-by: Chao Gao
---
Changes in v8:
- new
---
register an nmi callback. And this callback does busy-loop on threads
which are waiting for loading completion if 'loading_ucode' is true.
Signed-off-by: Chao Gao
---
Changes in v8:
- new
---
xen/arch/x86/microcode.c | 29 +
1 file changed, 29 insertion
hange is made in this patch. But following patch would
handle "old ucode" and "mismatched ucode" separately.
Signed-off-by: Chao Gao
---
Changes in v8:
- new
---
xen/arch/x86/microcode_amd.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Some callbacks in microcode_ops or related functions take a cpu
id parameter. But at current call sites, the cpu id parameter is
always equal to current cpu id. Some of them even use an assertion
to guarantee this. Remove this redundent 'cpu' parameter.
Signed-off-by: Chao Gao
---
Cha
esult will be used in common code
(aka microcode.c), it has been placed in the common header.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
---
Changes in v8:
- make sure enough room for an extended header and signature array
Changes in v6:
- eliminate unnecessary type casti
cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.
Signed-off-by: Chao Gao
Tested-by: Chao Gao
[linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
[linux commit
removed. It was used to free the "mc"
field to avoid memory leak.
Signed-off-by: Chao Gao
---
Changes in v8:
- split microcode_resume_cpu() cleanup to a separate patch.
Changes in v6:
- remove the whole struct ucode_cpu_info instead of the per-cpu cache
in it.
---
xen/arch/
rly during boot and SMP bring up.
While at it, protect early_microcode_update_cpu() for cases when
microcode_ops is NULL.
Signed-off-by: Sergey Dyasli
Signed-off-by: Chao Gao
---
Changes in v8:
- refine description.
- Jan asked if we could drop the call of collect_cpu_info() from
microcode_u
stored into the patch cache.
Signed-off-by: Chao Gao
---
Changes in v8:
- divide the original patch into three patches to improve readability
- load an update on each cpu as long as the update covers current cpu
- store an update after the first successful loading on a CPU
- Make sure the
Both are loading the cached patch. Since APs call the unified function,
microcode_update_one(), during wakeup, the 'start_update' parameter
which originally used to distinguish BSP and APs is redundant. So remove
this parameter.
Signed-off-by: Chao Gao
---
Changes in v8:
- split ou
This patch provides a tool for late microcode update.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Chao Gao
Acked-by: Andrew Cooper
---
Changes in v8:
- Correct two coding style issues. No functional changes.
Changes in v7:
- introduce xc_microcode_update() rather than xc_platform_op
Two buffers, '->equiv_cpu_table' and '->mpb', inside 'mc_amd' might be
allocated and in the error-handing path they are not freed properly.
Signed-off-by: Chao Gao
---
changes in v8:
- new
- it is found by reading code. No test is done.
---
xen/arch/x86/mi
' as I am going to
remove it completely in the next patch.
Signed-off-by: Chao Gao
---
Changes in v8:
- Free generic wrapper struct in general code
- Try to update cache as long as a patch covers current cpu. Previsouly,
cache is updated only if the patch is newer than current update revi
Introduce a vendor hook, .end_update, for svm_host_osvw_init().
The hook function is called on each cpu after loading an update.
It is a preparation for spliting out apply_microcode() from
cpu_request_microcode().
Signed-off-by: Chao Gao
---
Changes in v8:
- new
---
xen/arch/x86/microcode.c
m some related callbacks and functins
- save an ucode patch only if its supported CPU is allowed to mix with
current cpu.
Changes in version 5:
- support parallel microcode updates for all cores (see patch 8)
- Address Roger's comments on the last version.
Chao Gao (15):
misc/xen-u
On Wed, Jul 03, 2019 at 05:03:17PM +0100, Anthony PERARD wrote:
>On Wed, Jul 03, 2019 at 01:56:13PM +0800, Chao Gao wrote:
>> To remove a device from a domain, a qmp command is sent to qemu. But it is
>> handled by qemu asychronously. Even the qmp command is claimed to be done
ued by 'xl' or by pciback.
In order to avoid mentioned questions, wait for the completion of device
removal by querying all pci devices using qmp command and ensuring the target
device isn't listed. Only retry 5 times to avoid 'xl' potentially being blocked
by qemu.
Signed-
On Tue, Jul 02, 2019 at 02:42:33PM +0100, Anthony PERARD wrote:
>Hi,
>
>Thanks for the patch. I've got some comments.
>
>On Tue, Jul 02, 2019 at 03:46:40PM +0800, Chao Gao wrote:
>> To remove a device from a domain, a qmp command is sent to qemu. But it is
>> han
ued by 'xl' or by pciback.
In order to avoid mentioned questions, wait for the completion of device
removal by querying all pci devices using qmp command and ensuring the target
device isn't listed. Only retry 5 times to avoid 'xl' potentially being blocked
by qemu.
Signed
On Wed, Jun 26, 2019 at 03:36:35PM +0200, Juergen Gross wrote:
>On 26.06.19 14:21, Chao Gao wrote:
>>On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
>>>On 24.06.19 20:47, Stefano Stabellini wrote:
>>>>+ xen-devel
>>>>
>>>>On M
number as a
>selector.
>
>Fix that by adding a new member to struct libxl_device_type which when
>set is used to get the number of devices. Add such a member for pci to
>get the correct number of pci devices instead of implying it from the
>number of pci root devices (which will always be 1).
>
&
On Thu, Jun 13, 2019 at 08:08:46AM -0600, Jan Beulich wrote:
>>>> On 13.06.19 at 16:05, wrote:
>> On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
>>>>>> On 11.06.19 at 18:04, wrote:
>>>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Cha
On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
>>>> On 11.06.19 at 18:04, wrote:
>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
>>> On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
>>> >
>>> >> @@ -3
On Wed, Jun 05, 2019 at 04:56:01PM +0200, Roger Pau Monné wrote:
>On Mon, May 27, 2019 at 04:31:31PM +0800, Chao Gao wrote:
>> From: Sergey Dyasli
>>
>> Currently cpu_sig struct is not updated during boot when either:
>>
>> 1. ucode_scan is set to false
tpoline_safe() functions.
>>
>> Fix this by getting ucode revision early during boot and SMP bring up.
>> While at it.
>
>While at it?
>
>> Signed-off-by: Sergey Dyasli
>> Signed-off-by: Chao Gao
>> ---
>> changes in v7:
>> - rebase on p
lug and
>> late microcode update.
>>
>> Note that printk in apply_microcode() and svm_host_osvm_init() (for AMD
>> only) are still processed sequentially.
>>
>> Signed-off-by: Chao Gao
>
>Reviewed-by: Jan Beulich
Thanks.
>
>> ---
>>
as possible and
>> avoid potential issues caused by the microcode update.
>>
>> Signed-off-by: Chao Gao
>> Tested-by: Chao Gao
>> [linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
>> [linux commit: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7]
>>
On Tue, Jun 11, 2019 at 01:08:36AM -0600, Jan Beulich wrote:
On 11.06.19 at 05:32, wrote:
>> On Wed, Jun 05, 2019 at 06:37:27AM -0600, Jan Beulich wrote:
>> On 27.05.19 at 10:31, wrote:
During late microcode update, apply_microcode() is invoked in
cpu_request_microcode(). To ma
On Wed, Jun 05, 2019 at 06:37:27AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> During late microcode update, apply_microcode() is invoked in
>> cpu_request_microcode(). To make late microcode update more reliable,
>> we want to put the apply_microcode() into stop_machine context
On Tue, Jun 04, 2019 at 09:29:34AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> --- a/xen/arch/x86/microcode_amd.c
>> +++ b/xen/arch/x86/microcode_amd.c
>> @@ -78,8 +78,9 @@ struct mpbhdr {
>> static DEFINE_SPINLOCK(microcode_update_lock);
>>
>> /* See comment in start_update
On Tue, Jun 04, 2019 at 09:13:46AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> We can remove the per-cpu cache field in struct ucode_cpu_info since
>> it has been replaced by a global cache. It would leads to only one field
>> remaining in ucode_cpu_info. Then, this struct is re
On Tue, Jun 04, 2019 at 09:03:20AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> +bool microcode_update_cache(struct microcode_patch *patch)
>> +{
>> +
>> +ASSERT(spin_is_locked(µcode_mutex));
>> +
>> +if ( !microcode_ops->match_cpu(patch) )
>> +return false;
>> +
On Tue, Jun 04, 2019 at 08:39:15AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> --- a/xen/arch/x86/microcode_intel.c
>> +++ b/xen/arch/x86/microcode_intel.c
>> @@ -134,14 +134,28 @@ static int collect_cpu_info(unsigned int cpu_num,
>> struct cpu_signature *csig)
>> return 0
On Tue, Jun 04, 2019 at 05:14:14PM +0100, Andrew Cooper wrote:
>On 27/05/2019 09:31, Chao Gao wrote:
>> This patch provides a tool for late microcode update.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>> Signed-off-by: Chao Gao
>> ---
>> Changes in
This patch provides a tool for late microcode update.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Chao Gao
---
Changes in v7:
- introduce xc_microcode_update() rather than xc_platform_op()
- avoid creating bounce buffer twice
- rename xenmicrocode to xen-ucode, following naming
cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.
Signed-off-by: Chao Gao
Tested-by: Chao Gao
[linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
[linux commit
update after system bootup
* don't bring all pCPUs up at bootup by specifying maxcpus option in xen
command line and then do a microcode update and online all offlined
CPUs via 'xen-hptool'.
Chao Gao (9):
misc/xen-ucode: Upload a microcode blob to the hypervisor
microcode/intel:
'microcode_resume_match' from microcode_ops because the
check is done in find_patch(). The cpu status notifier is also
removed. It was used to free the "mc" field to avoid memory leak.
Signed-off-by: Chao Gao
---
Changes in v6:
- remove the whole struct ucode_cpu_info instead of the per-cpu ca
hardly
noticable. Although only BDX with an old microcode needs this fix, we
would like to avoid future issues in case they come by later due to
other reasons.
[linux commit: 91df9fdf51492aec9fed6b4cbd33160886740f47]
Signed-off-by: Chao Gao
Cc: Ashok Raj
---
Changes in v7:
- explain why we do
esult will be used in common code
(aka microcode.c), it has been placed in the common header.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
---
Changes in v6:
- eliminate unnecessary type casting in microcode_update_match
- check if a patch has an extend header
Changes in v5:
- constif
Some callbacks in microcode_ops or related functions take a cpu
id parameter. But at current call sites, the cpu id parameter is
always equal to current cpu id. Some of them even use an assertion
to guarantee this. Remove this redundent 'cpu' parameter.
Signed-off-by: Chao Gao
---
xe
tely avoid touching 'uci->mc' as I am going to
remove it completely in the next patch.
Signed-off-by: Chao Gao
---
Changes in v7:
- reworked to cache only one microcode patch rather than a list of
microcode patches.
Changes in v6:
- constify local variables and function pa
ne_errata() and retpoline_safe() functions.
Fix this by getting ucode revision early during boot and SMP bring up.
While at it.
Signed-off-by: Sergey Dyasli
Signed-off-by: Chao Gao
---
changes in v7:
- rebase on patch 1~9
---
xen/arch/x86/microcode.c | 4
1 file changed, 4 insertions(+)
d
moved out of
microcode_update_cpu().
On AMD side, svm_host_osvw_init() is supposed to be called after
microcode update. As apply_micrcode() won't be called by
cpu_request_microcode() now, svm_host_osvw_init() is moved to the
end of apply_microcode().
Signed-off-by: Chao Gao
---
Changes in v
of logical threads.
3.get/put_cpu_bitmaps() prevents the concurrency of CPU-hotplug and
late microcode update.
Note that printk in apply_microcode() and svm_host_osvm_init() (for AMD
only) are still processed sequentially.
Signed-off-by: Chao Gao
---
Changes in v7:
- reworked. Remove complex
On Mon, May 06, 2019 at 03:39:40AM -0600, Jan Beulich wrote:
On 06.05.19 at 06:44, wrote:
>> On Thu, May 02, 2019 at 10:20:09AM +0200, Roger Pau Monné wrote:
>>>Can you see about avoiding the XEN_DOMCTL_bind_pt_irq call in QEMU if
>>>the interrupt is going to be routed over an event channel?
On Thu, May 02, 2019 at 10:20:09AM +0200, Roger Pau Monné wrote:
>On Wed, May 01, 2019 at 12:41:13AM +0800, Chao Gao wrote:
>> On Tue, Apr 30, 2019 at 11:30:33AM +0200, Roger Pau Monné wrote:
>> >On Tue, Apr 30, 2019 at 05:01:21PM +0800, Chao Gao wrote:
>> >> On T
On Tue, Apr 30, 2019 at 11:30:33AM +0200, Roger Pau Monné wrote:
>On Tue, Apr 30, 2019 at 05:01:21PM +0800, Chao Gao wrote:
>> On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
>> >>>> On 30.04.19 at 07:19, wrote:
>> >> When testing with an UP gue
On Tue, Apr 30, 2019 at 11:08:54AM +0200, Roger Pau Monné wrote:
>On Tue, Apr 30, 2019 at 01:19:19PM +0800, Chao Gao wrote:
>> When testing with an UP guest with a pass-thru device with vt-d pi
>> enabled in host, we observed that guest couldn't receive interrupts
>>
On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
On 30.04.19 at 07:19, wrote:
>> When testing with an UP guest with a pass-thru device with vt-d pi
>> enabled in host, we observed that guest couldn't receive interrupts
>> from that pass-thru device. Dumping IRTE, we found the corr
this issue when guest used the pirq format of MSI
(see the comment xen_msi_compose_msg() in linux kernel). As 'dest_id'
is repurposed, skip migration which is based on 'dest_id'.
Signed-off-by: Chao Gao
---
xen/drivers/passthrough/io.c | 68
On Mon, Mar 25, 2019 at 09:38:21AM +, Sergey Dyasli wrote:
>On 11/03/2019 07:57, Chao Gao wrote:
>> This patch provides a tool for late microcode update.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>> Signed-off-by: Chao Gao
>> ---
>> tools/libxc/i
On Mon, Apr 01, 2019 at 11:19:19AM +0100, Sergey Dyasli wrote:
>On 25/03/2019 17:08, Jan Beulich wrote:
> On 25.03.19 at 12:12, wrote:
>>> Currently cpu_sig struct is not updated during boot when either:
>>>
>>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>>> 2. ini
in cpu_sig.rev being 0 which affects APIC's
>check_deadline_errata() and retpoline_safe() functions.
>
>Fix this by getting ucode revision early during boot and SMP bring up.
>While at it, protect early_microcode_update_cpu() for cases when
>microcode_ops is NULL.
>
&g
On Thu, Mar 21, 2019 at 12:24:46PM +, Sergey Dyasli wrote:
>Hi Chao,
>
>Updating microcode in parallel by default should be fine, but I think
>there are no guarantees that a parallel application will be fine for
>all future microcodes. To retain the ability to update microcode on cores
>sequent
On Tue, Mar 19, 2019 at 09:39:59PM +, Woods, Brian wrote:
>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 too
On Wed, Mar 13, 2019 at 02:02:55AM -0600, Jan Beulich wrote:
>>>> On 13.03.19 at 08:54, wrote:
>>>>> On 13.03.19 at 06:02, wrote:
>>> On Tue, Mar 12, 2019 at 05:07:51PM -0700, Raj, Ashok wrote:
>>>>On Mon, Mar 11, 2019 at 03:57:35PM +0800, Chao
On Wed, Mar 13, 2019 at 04:36:50PM +, Sergey Dyasli wrote:
>On 11/03/2019 07:57, Chao Gao wrote:
>> to replace the current per-cpu cache 'uci->mc'.
>>
>> Compared to the current per-cpu cache, the benefits of the global
>> microcode cache are:
>>
Thanks for your great suggestion.
On Tue, Mar 12, 2019 at 05:53:53PM +0100, Roger Pau Monné wrote:
>On Mon, Mar 11, 2019 at 03:57:28PM +0800, Chao Gao wrote:
>> to replace the current per-cpu cache 'uci->mc'.
>>
>> Compared to the current per-cpu cache, the b
On Tue, Mar 12, 2019 at 04:27:33PM +0100, Roger Pau Monné wrote:
>On Mon, Mar 11, 2019 at 03:57:25PM +0800, Chao Gao wrote:
>> This patch provides a tool for late microcode update.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>> Signed-off-by: Chao Gao
>> ---
On Tue, Mar 12, 2019 at 05:07:51PM -0700, Raj, Ashok wrote:
>On Mon, Mar 11, 2019 at 03:57:35PM +0800, Chao Gao wrote:
>> This patch ports microcode improvement patches from linux kernel.
>>
>> Before you read any further: the early loading method is still the
>> p
d, irq{save, restore} variants are used to
get/release the rwlock.
Note that printk in apply_microcode() and svm_host_osvm_init() (for AMD
only) are still processed sequentially.
Signed-off-by: Chao Gao
---
Changes in v6:
- introduce early_ucode_update_lock to serialize early ucode update.
Changes
s option in xen
command line and then do a microcode update and online all offlined
CPUs via 'xen-hptool'.
Chao Gao (12):
misc/xenmicrocode: Upload a microcode blob to the hypervisor
microcode/intel: use union to get fields without shifting and masking
microcode/intel: extend m
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode_intel.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index 9657575..22fdeca 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86
cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.
Signed-off-by: Chao Gao
Tested-by: Chao Gao
[linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
[linux commit
This patch provides a tool for late microcode update.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Chao Gao
---
tools/libxc/include/xenctrl.h | 1 +
tools/libxc/xc_misc.c | 20 ++
tools/misc/Makefile | 4 ++
tools/misc/xenmicrocode.c | 89
'microcode_resume_match' from microcode_ops because the
check is done in find_patch(). The cpu status notifier is also
removed. It was used to free the "mc" field to avoid memory leak.
Signed-off-by: Chao Gao
---
Changes in v6:
- remove the whole struct ucode_cpu_info instead of the per-cpu ca
Intel CPU only allows mixing in stepping or 'pf'. If an ucode patch is
for other CPU families or models, it won't be compatible to all CPUs on
current system and even hot-plugged CPUs. Don't save such patch to
reduce the size of ucode cache.
Signed-off-by: Chao Gao
---
v6:
also redundent because it always can be inferred from
current cpu id.
Signed-off-by: Chao Gao
---
v6:
- remove the whole microcode_info instead of two fields of it.
---
xen/arch/x86/microcode.c | 62 +++-
1 file changed, 25 insertions(+), 37 deletions
Some callbacks in microcode_ops or related functions take a cpu
id parameter. But at current call sites, the cpu id parameter is
always equal to current cpu id. Some of them even use an assertion
to guarantee this. Remove this redundent 'cpu' parameter.
Signed-off-by: Chao Gao
---
xe
esult will be used in common code
(aka microcode.c), it has been placed in the common header.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
---
Changes in v6:
- eliminate unnecessary type casting in microcode_update_match
- check if a patch has an extend header
Changes in v5:
- constif
;t be called by
cpu_request_microcode() now, svm_host_osvw_init() is moved to the
end of apply_microcode().
Signed-off-by: Chao Gao
---
Changes in v6:
- during early microcode update, BSP and APs call different functions.
Thus AP can bypass parsing microcode blob.
---
xen/arch/x86/acpi/po
and matched ucode patch from the global cache.
All operations on the cache is expected to be done with the
'microcode_mutex' hold.
Note that I deliberately avoid touching 'uci->mc' as I am going to
remove it completely in the next patch.
Signed-off-by: Chao Gao
---
Chang
]
Signed-off-by: Chao Gao
Cc: Ashok Raj
---
Changes in v6:
- new
---
xen/arch/x86/microcode_intel.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index c921ea9..d5ef145 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch
On Wed, Feb 13, 2019 at 12:20:51AM -0700, Jan Beulich wrote:
On 13.02.19 at 03:30, wrote:
>> On Tue, Feb 12, 2019 at 06:55:20AM -0700, Jan Beulich wrote:
>> On 12.02.19 at 14:25, wrote:
On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
> >>> On 28.01.19 at 08:06, wro
On Tue, Feb 12, 2019 at 06:55:20AM -0700, Jan Beulich wrote:
On 12.02.19 at 14:25, wrote:
>> On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
>>> >>> On 28.01.19 at 08:06, wrote:
>>> > @@ -314,9 +310,7 @@ static int apply_microcode(unsigned int cpu)
>>> >
>>> > mc_intel =
On Fri, Feb 08, 2019 at 09:29:32AM -0700, Jan Beulich wrote:
On 28.01.19 at 08:06, wrote:
>> @@ -30,18 +31,25 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> +#include
>>
>> +#include
>> #include
>> #include
>> #include
>> #in
On Fri, Feb 08, 2019 at 04:41:19AM -0700, Jan Beulich wrote:
On 28.01.19 at 08:06, wrote:
>> @@ -208,6 +210,58 @@ static void microcode_fini_cpu(unsigned int cpu)
>> spin_unlock(µcode_mutex);
>> }
>>
>> +/* Save a ucode patch to the global cache list */
>> +bool save_patch(struct micr
On Tue, Jan 29, 2019 at 11:37:12AM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:49PM +0800, Chao Gao wrote:
>> This patch ports microcode improvement patches from linux kernel.
>>
>> Before you read any further: the early loading method is still the
>> p
On Tue, Jan 29, 2019 at 12:27:30PM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:50PM +0800, Chao Gao wrote:
>> Currently, microcode_update_lock and microcode_mutex prevent cores
>> from updating microcode in parallel. Below changes are made to support
>> para
On Tue, Jan 29, 2019 at 11:10:51AM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:48PM +0800, Chao Gao wrote:
>> microcode pointer and size were passed to other CPUs to parse
>> microcode locally. Now, parsing microcode is done on one CPU.
>> Other CPUs needn&
On Tue, Jan 29, 2019 at 03:41:09AM -0700, Jan Beulich wrote:
>>>> Chao Gao 01/28/19 8:10 AM >>>
>>--- a/xen/arch/x86/microcode_intel.c
>>+++ b/xen/arch/x86/microcode_intel.c
>>@@ -127,14 +127,24 @@ static int collect_cpu_info(unsigned int cpu_num,
&
On Tue, Jan 29, 2019 at 03:26:18AM -0700, Jan Beulich wrote:
>>>> Chao Gao 01/28/19 8:06 AM >>>
>>This check has been done in microcode_sanity_check(). Needn't do it
>>again in get_matching_microcode().
>
>But while there are two call sites of get_mat
On Tue, Jan 29, 2019 at 10:25:03AM +0100, Roger Pau Monné wrote:
>Thanks for the cleanup!
>
>On Mon, Jan 28, 2019 at 03:06:46PM +0800, Chao Gao wrote:
>> diff --git a/xen/include/asm-x86/microcode.h
>> b/xen/include/asm-x86/microcode.h
>> index fc98fed..507da2e 100644
&
On Tue, Jan 29, 2019 at 10:58:11AM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:47PM +0800, Chao Gao wrote:
>> During late microcode update, apply_microcode() is invoked in
>> cpu_request_microcode(). To make late microcode update more reliable,
>&g
On Tue, Jan 29, 2019 at 12:31:51PM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:42PM +0800, Chao Gao wrote:
>> Changes in this version:
>> - support parallel microcode updates for all cores (see patch 8)
>> - Address Roger's comments on the last versio
On Mon, Jan 28, 2019 at 06:39:43PM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:45PM +0800, Chao Gao wrote:
>> to replace the current per-cpu cache 'uci->mc'.
>>
>> Compared to the current per-cpu cache, the benefits of the global
>> microc
On Fri, Jan 25, 2019 at 09:13:49AM -0700, Jan Beulich wrote:
On 25.01.19 at 09:26, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -732,7 +732,11 @@ long arch_do_domctl(
>> break;
>>
>> ret = -EPERM;
>> -if ( irq <= 0 || !irq_access_p
cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.
Signed-off-by: Chao Gao
Tested-by: Chao Gao
[linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
[linux commit
to a more generic function. Then, this function can compare two given
microcodes' signature/revision as well. Comparing two microcodes is
used to update the global microcode cache (introduced by the later
patches in this series) when a new microcode is given.
Signed-off-by: Chao Gao
---
Ch
microcode pointer and size were passed to other CPUs to parse
microcode locally. Now, parsing microcode is done on one CPU.
Other CPUs needn't parse the microcode blob; the pointer and
size can be removed.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c
101 - 200 of 353 matches
Mail list logo
