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 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 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
>> from
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
1 file changed, 43
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
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?
' 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-off-by: Chao Gao
---
Changes in v2
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).
>
>While a
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
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
>> handled
' 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-off-by: Chao Gao
---
tools/libxl
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
going to remove it completely in the following patches. We copy
everything to create the new cache blob to avoid reusing some buffers
previously allocated for the old per-cpu cache. It is not so efficient,
but it is already corrected by a patch later in this series.
Signed-off-by: Chao Gao
-
to a more generic function. So that it can be used alone to check
an update against the CPU signature and current update revision.
Note that enum microcode_match_result will be used in common code
(aka microcode.c), it has been placed in the common header.
Signed-off-by: Chao Gao
Reviewed
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
Reviewed-by: Jan Beulich
---
Changes in v9:
- use xzalloc() to get rid of explicitly initializing some fields
to
removed. It was used to free the "mc"
field to avoid memory leak.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
Changes in v9:
- rebase and fix conflict
Changes in v8:
- split microcode_resume_cpu() cleanup to a separate patch.
Changes in v6:
- remove the whole struct ucod
is made in this patch. But following patch would
handle "old ucode" and "mismatched ucode" separately.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
Changes in v8:
- new
---
xen/arch/x86/microcode_amd.c | 18 +-
1 file changed, 9 insertions(+), 9 dele
a 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
Reviewed-by: Jan Beulich
---
changes in v8:
- new
- separated from the following patch
---
xen/arch/x86/microcode.c|
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
---
Note that here is a functional change
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):
microcode/intel: extend microcode_update_match()
microcode/amd
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
register an nmi callback. And this callback does busy-loop on threads
which are waiting for loading completion. Control threads send NMI to
slave threads to prevent NMI acceptance during ucode loading.
Signed-off-by: Chao Gao
---
Changes in v9:
- control threads send NMI to all other threads
On Mon, Aug 19, 2019 at 11:27:36AM +0100, Sergey Dyasli wrote:
>> +static int master_thread_fn(const struct microcode_patch *patch)
>> +{
>> +unsigned int cpu = smp_processor_id();
>> +int ret = 0;
>> +
>> +while ( loading_state != LOADING_CALLIN )
>> +cpu_relax();
>> +
>> +
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
Reviewed-by: Jan Beulich
---
xen
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
Reviewed-by: Jan
, buffers
like mc_amd, equiv_cpu_table (on AMD side), and mc (on Intel
side) can be reused. microcode_patch now is allocated after
it is sure that there is a matching ucode.
Signed-off-by: Chao Gao
---
Changes in v9:
- new
---
xen/arch/x86/microcode_amd.c | 99
be stored into the patch cache.
Signed-off-by: Chao Gao
---
Changes in v9:
- remove the calling of ->compare_patch in microcode_update_cpu().
- drop "microcode_" prefix for static function - microcode_parse_blob().
- rebase and fix conflict
Changes in v8:
- divide the original pat
an update.
Signed-off-by: Chao Gao
---
Changes in v9:
- call .end_update in early loading path
- on AMD side, initialize .{start,end}_update only if "CONFIG_HVM"
is true.
---
xen/arch/x86/microcode.c| 10 +-
xen/arch/x86/microcode_amd.c| 23 ++
On Thu, Aug 22, 2019 at 08:51:43AM +0100, Sergey Dyasli wrote:
>Hi Chao,
>
>On 19/08/2019 02:25, Chao Gao wrote:
>> Previous change log:
>> Changes in version 8:
>> - block #NMI handling during microcode loading (Patch 16)
>> - Don't assume that all CPUs in th
On Tue, Aug 27, 2019 at 12:17:28AM +0300, Pasi Kärkkäinen wrote:
>Hi Chao,
>
>On Fri, Aug 09, 2019 at 04:38:33PM +0800, Chao Gao wrote:
>> Hi everyone,
>>
>> I have a device which only supports secondary bus reset. After being
>> assigned to a VM, it would be plac
On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>>On 19/08/2019 02:25, Chao Gao wrote:
>>> register an nmi callback. And this callback does busy-loop on threads
>>> which are waiting for loading
On Fri, Aug 30, 2019 at 09:49:04AM +0200, Jan Beulich wrote:
>On 30.08.2019 04:09, Chao Gao wrote:
>> On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> While testing xen-unstable, my AMD system crashes during ear
On Thu, Aug 29, 2019 at 02:22:47PM +0200, Jan Beulich wrote:
>On 19.08.2019 03:25, Chao Gao wrote:
>> @@ -481,12 +478,28 @@ static int do_microcode_update(void *patch)
>> return ret;
>> }
>>
>> +static int microcode_nmi_callback(const st
On Thu, Aug 29, 2019 at 02:11:10PM +0200, Jan Beulich wrote:
>On 27.08.2019 06:52, Chao Gao wrote:
>> On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>>> On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>>>> On 19/08/2019 02:25, Chao Ga
On Fri, Aug 23, 2019 at 11:09:07AM +0200, Roger Pau Monné wrote:
>On Fri, Aug 23, 2019 at 12:44:34AM +0800, Chao Gao wrote:
>> On Thu, Aug 22, 2019 at 04:10:46PM +0200, Roger Pau Monné wrote:
>> >On Mon, Aug 19, 2019 at 09:25:24AM +0800, Chao Gao wrote:
>> >> Bot
guest, deleting
emulated registers), then initiate PCI reset through 'reset' knob under the
device's sysfs, finally initialize the device again.
Signed-off-by: Chao Gao
---
Do we need to introduce an attribute, like "permissive" to explicitly
enable FLR capability emulation? During
On Wed, Aug 28, 2019 at 05:12:34PM +0200, Jan Beulich wrote:
>On 19.08.2019 03:25, Chao Gao wrote:
>> to a more generic function. So that it can be used alone to check
>> an update against the CPU signature and current update revision.
>>
>> Note that enum microcod
On Thu, Aug 29, 2019 at 12:03:44PM +0200, Jan Beulich wrote:
>On 29.08.2019 11:02, Chao Gao wrote:
>> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
>> perspective, assigned devices cannot be reset. But some devices rely on PCI
>> reset to recove
On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote:
>L.S.,
>
>While testing xen-unstable, my AMD system crashes during early boot while
>loading microcode with an "Early fatal page fault".
>Reverting commit de45e3ff37bb1602796054afabfa626ea5661c45 "microcode/amd: fix
>memory
On Thu, Aug 29, 2019 at 12:06:28PM +0200, Jan Beulich wrote:
>On 22.08.2019 15:59, Roger Pau Monné wrote:
>> Seeing how this works I'm not sure what's the best option here. As
>> updating will be attempted on other CPUs, I'm not sure if it's OK to
>> return an error if the update succeed on some
On Thu, Aug 29, 2019 at 02:06:39PM +0200, Jan Beulich wrote:
>On 19.08.2019 03:25, Chao Gao wrote:
>> +
>> +static int master_thread_fn(const struct microcode_patch *patch)
>> +{
>> +unsigned int cpu = smp_processor_id();
>> +int ret = 0;
&
On Fri, Aug 23, 2019 at 10:11:21AM +0200, Roger Pau Monné wrote:
>On Mon, Aug 19, 2019 at 09:25:25AM +0800, Chao Gao wrote:
>> To create a microcode patch from a vendor-specific update,
>> allocate_microcode_patch() copied everything from the update.
>> It is not efficient.
On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>On 19/08/2019 02:25, Chao Gao wrote:
>> register an nmi callback. And this callback does busy-loop on threads
>> which are waiting for loading completion. Control threads send NMI to
>> slave threads to prevent
On Thu, Aug 22, 2019 at 04:10:46PM +0200, Roger Pau Monné wrote:
>On Mon, Aug 19, 2019 at 09:25:24AM +0800, Chao Gao wrote:
>> Both are loading the cached patch. Since APs call the unified function,
>> microcode_update_one(), during wakeup, the 'start_update' parameter
>>
On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote:
>On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote:
>> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
>> perspective, assigned devices cannot be reset. But some devices rely
is made in this patch. But following patch would
handle "old ucode" and "mismatched ucode" separately.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
Changes in v8:
- new
---
xen/arch/x86/microcode_amd.c | 18 +-
1 file changed, 9 insertions(+), 9 dele
ve it completely in the following patches. We copy
everything to create the new cache blob to avoid reusing some buffers
previously allocated for the old per-cpu cache. It is not so efficient,
but it is already corrected by a patch later in this series.
Signed-off-by: Chao Gao
Reviewed-by:
It ports the implementation of is_blacklisted() in linux kernel
to Xen.
Late loading may cause system hang if CPUs are affected by BDF90.
Check against BDF90 before performing a late loading.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c| 6 ++
xen/arch/x86
of loading an update.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
---
Changes in v10:
- rename end_update to end_update_percpu.
- use #ifdef rather than #if and frame the implementation with
Changes in v9:
- call .end_update in early loading path
- on AMD side, initialize .{start,end
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
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 (16):
microcode/intel: extend microcode_update_match()
microcode/amd: distinguish old and mismatched ucode in
microcode_fits()
microc
apply_microcode()'s always loading the cached ucode patch forces
a patch to be stored before being loaded. 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
Reviewed-by: Jan Beulich
---
xen
be stored into the patch cache.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
---
Changes in v10:
- make microcode_update_cache static
- raise an error if loading ucode failed with -EIO
- ensure end_update_percpu() is called following a successful call of
start_update()
Changes in v9
of microcode_sanity_check() such that it
can be called by microcode_update_match().
Signed-off-by: Chao Gao
---
Changes in v10:
- Drop RBs
- assert that microcode passed to microcode_update_match() would pass
sanity check. Constify the parameter of microcode_sanity_check()
Changes in v9
It is needed to mitigate some issues on this specific Broadwell CPU.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode_intel.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index bcef668..4e5e7f9
, buffers
like mc_amd, equiv_cpu_table (on AMD side), and mc (on Intel
side) can be reused. microcode_patch now is allocated after
it is sure that there is a matching ucode.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
---
Changes in v10:
- avoid unnecessary type casting
* introduce
ion), start_update is always true and so remove
this parameter.
There is a functional change: ->start_update is called on BSP and
->end_update_percpu is called during system resuming. They are not
invoked by previous microcode_resume_cpu().
Signed-off-by: Chao Gao
---
Changes in v10:
- call ->
a 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
Reviewed-by: Jan Beulich
---
changes in v8:
- new
- separated from the following patch
---
xen/arch/x86/microcode.c|
removed. It was used to free the "mc"
field to avoid memory leak.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
Changes in v9:
- rebase and fix conflict
Changes in v8:
- split microcode_resume_cpu() cleanup to a separate patch.
Changes in v6:
- remove the whole struct ucod
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
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
Reviewed-by: Jan
. Primary threads call in and load ucode in
NMI handler. Secondary threads wait for the completion of ucode
loading on all CPU cores. An option is introduced to disable this
behavior.
Signed-off-by: Chao Gao
Signed-off-by: Sergey Dyasli
---
Changes in v10:
- rewrite based on Sergey's idea and patch
CPU topology support (RFC)
> - Chao Gao
No plan to continue this one due to some reason. Please drop this one.
>
>* Improve late microcode loading (v9)
> - Chao Gao
>
Working on the v10. I would like to get it merged in 4.13.
Thanks
Chao
__
On Fri, Sep 13, 2019 at 10:02:24AM +, Spassov, Stanislav wrote:
>On Thu, Dec 13, 2018 at 07:54, Chao Gao wrote:
>>On Thu, Dec 13, 2018 at 12:54:52AM -0700, Jan Beulich wrote:
>>>>>> On 13.12.18 at 04:46, wrote:
>>>> On Wed, Dec 12, 2018
On Fri, Aug 30, 2019 at 02:35:06PM +0800, Chao Gao wrote:
>On Thu, Aug 29, 2019 at 02:11:10PM +0200, Jan Beulich wrote:
>>On 27.08.2019 06:52, Chao Gao wrote:
>>> On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>>>> On Fri, Aug 23, 2019 at 09:46:3
On Fri, Sep 13, 2019 at 10:47:36AM +0200, Jan Beulich wrote:
>On 12.09.2019 09:22, Chao Gao wrote:
>> This series includes below changes:
>> 1. Patch 1-11: introduce a global microcode cache and some cleanup
>> 2. Patch 12: synchronize late microcode loading
>> 3.
On Fri, Sep 13, 2019 at 11:22:59AM +0200, Jan Beulich wrote:
>On 12.09.2019 09:22, Chao Gao wrote:
>> @@ -283,6 +284,27 @@ static enum microcode_match_result compare_patch(
>> : OLD_UCODE;
>> }
>>
>>
On Fri, Sep 13, 2019 at 11:14:59AM +0200, Jan Beulich wrote:
>On 12.09.2019 09:22, Chao Gao wrote:
>> When one core is loading ucode, handling NMI on sibling threads or
>> on other cores in the system might be problematic. By rendezvousing
>> all CPUs in NMI handler, it pr
On Thu, Sep 12, 2019 at 04:07:16PM +0200, Jan Beulich wrote:
>On 12.09.2019 09:22, Chao Gao wrote:
>> @@ -249,49 +249,80 @@ bool microcode_update_cache(struct microcode_patch
>> *patch)
>> return true;
>> }
>>
>> -static int microcode_
On Thu, Sep 12, 2019 at 05:32:22PM +0200, Jan Beulich wrote:
>On 12.09.2019 09:22, Chao Gao wrote:
>> @@ -264,38 +336,158 @@ static int microcode_update_cpu(const struct
>> microcode_patch *patch)
>> return err;
>> }
>>
>> -static long do_microc
On Fri, Sep 13, 2019 at 08:50:59AM +0200, Jan Beulich wrote:
>On 12.09.2019 12:24, Jan Beulich wrote:
>> On 12.09.2019 09:22, Chao Gao wrote:
>>> --- a/xen/arch/x86/microcode_intel.c
>>> +++ b/xen/arch/x86/microcode_intel.c
>>> @@ -134,21 +134,11 @@ static int c
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,
>>
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 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(_mutex));
>> +
>> +if ( !microcode_cach
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 Mon, Aug 05, 2019 at 12:11:01PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> @@ -439,12 +440,37 @@ static int do_microcode_update(void *patch)
>> return ret;
>> }
>>
>> +static int microcode_nmi_callback(const st
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
---
xen
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 insertions(+)
diff
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(-)
diff
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
---
Changes in v8
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 casting
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 out from
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/
uring 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_
be 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
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
a 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|
tely 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 revision in
the CPU. The small difference
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
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-ucode: Upload a microcode blob to the hypervisor
microcode/intel
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/microcode_amd.c | 14 +++
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
>>>
Hi everyone,
I have a device which only supports secondary bus reset. After being
assigned to a VM, it would be placed under host bridge. For devices
under host bridge, secondary bus reset is not applicable. Thus, a VM
has no way to reset this device.
This device's usage would be limited without
On Fri, Aug 09, 2019 at 02:42:09PM +0200, Roger Pau Monné wrote:
>On Fri, Aug 09, 2019 at 04:38:33PM +0800, Chao Gao wrote:
>> Hi everyone,
>>
>> I have a device which only supports secondary bus reset. After being
>> assigned to a VM, it would be placed under host b
On Fri, Aug 09, 2019 at 03:23:59PM +0200, Jan Beulich wrote:
>On 09.08.2019 15:24, Chao Gao wrote:
>>On Fri, Aug 09, 2019 at 10:49:32AM +0200, Jan Beulich wrote:
>>>On 09.08.2019 10:38, Chao Gao wrote:
>>>>Alternatively, emulating FLR (Function Level Reset)
>&g
201 - 300 of 337 matches
Mail list logo
