On Wed, Sep 20, 2017 at 04:13:43PM +0100, Wei Liu wrote:
>On Tue, Sep 19, 2017 at 11:06:26AM +0800, Lan Tianyu wrote:
>> Hi Wei:
>>
>> On 2017年09月18日 21:06, Wei Liu wrote:
>> > On Wed, Sep 13, 2017 at 12:52:47AM -0400, Lan Tianyu wrote:
>> >> This patch is to increase page pool size when max vcpu
quot;Device" syntax for other vcpus in ACPI DSDT table.
3) Use XAPIC structure for vcpus with APIC id < 255
in dsdt and use x2APIC structure for other vcpus in the ACPI MADT table.
This patchset is to extend some resources(i.e, event channel,
hap and so) to support more vcpus for single
* HVM_MAX_VCPUS
for shadow case.
This patch won't lead to more memory consumption for the size of shadow memory
will be adjusted via XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION according to the size
of guest memory and the number of vcpus.
Signed-off-by: Chao Gao
---
xen/arch/x86/mm/hap/hap.c
There were two places where the lapic_id is computed, one in hvmloader and one
in libacpi. Unify them by defining LAPIC_ID in a header file and incluing it
in both places.
To address compilation issue and make libacpi.h self-contained, include
stdint.h in libacpi.h.
Signed-off-by: Chao Gao
It is a preparation to support multiple IOREQ pages.
No functional change.
Signed-off-by: Chao Gao
---
v4:
-new
---
xen/arch/x86/hvm/ioreq.c | 48 +++-
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen
operation, the
index increases by 1 and rewinds when it overflows.
Signed-off-by: Chao Gao
---
v4:
- new
---
tools/libxc/include/xc_dom.h | 2 +-
tools/libxc/xc_dom_x86.c | 6 +-
xen/arch/x86/hvm/hvm.c | 1 +
xen/arch/x86/hvm/ioreq.c | 116
Structure.
Signed-off-by: Lan Tianyu
Signed-off-by: Chao Gao
---
v4:
- also add x2apic entry in SRAT
---
tools/libacpi/acpi2_0.h | 25 --
tools/libacpi/build.c | 57 +++--
2 files changed, 69 insertions(+), 13 deletions(-)
diff --git a
duced to protect the stack.
Signed-off-by: Chao Gao
---
v4:
- new
---
tools/firmware/hvmloader/apic_regs.h | 4 +++
tools/firmware/hvmloader/smp.c | 64
2 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/tools/firmware/hvmloader/apic_regs.h
Signed-off-by: Chao Gao
---
xen/include/public/hvm/hvm_info_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/public/hvm/hvm_info_table.h
b/xen/include/public/hvm/hvm_info_table.h
index 08c252e..6833a4c 100644
--- a/xen/include/public/hvm/hvm_info_table.h
of CPU ID used to compose processor name to 12 bits. Thus
the processors number limitation imposed here is 4096.
Signed-off-by: Lan Tianyu
Signed-off-by: Chao Gao
---
tools/libacpi/libacpi.h | 6 ++
tools/libacpi/mk_dsdt.c | 40 +---
2 files changed
On Wed, Dec 06, 2017 at 02:44:52PM +, Paul Durrant wrote:
>> -Original Message-
>> From: Chao Gao [mailto:chao@intel.com]
>> Sent: 06 December 2017 07:50
>> To: xen-de...@lists.xen.org
>> Cc: Chao Gao ; Andrew Cooper
>> ; Jan Beulich ; Paul
>&
On Wed, Dec 06, 2017 at 03:04:11PM +, Paul Durrant wrote:
>> -Original Message-
>> From: Chao Gao [mailto:chao@intel.com]
>> Sent: 06 December 2017 07:50
>> To: xen-de...@lists.xen.org
>> Cc: Chao Gao ; Paul Durrant
>> ; Tim (Xen.org) ; Stefano S
On Tue, Nov 28, 2017 at 03:08:46PM +, Paul Durrant wrote:
>A subsequent patch will introduce a new scheme to allow an emulator to
>map ioreq server pages directly from Xen rather than the guest P2M.
>
>This patch lays the groundwork for that change by deferring mapping of
>gfns until their valu
On Thu, Dec 07, 2017 at 08:41:14AM +, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 06 December 2017 16:10
>> To: 'Chao Gao'
>> Cc: S
On Mon, Dec 11, 2017 at 05:59:08PM +, Anthony PERARD wrote:
>On Fri, Nov 17, 2017 at 02:24:24PM +0800, Chao Gao wrote:
>> Previously, some fields (reserved or unalterable) are filtered by
>> Qemu. This fields are useless for the legacy interrupt format.
>> However,
On Mon, Dec 11, 2017 at 06:07:48PM +, Anthony PERARD wrote:
>On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote:
>> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
>> Interrupt Remapping -> Interrupt Request Formats On Intel 64
>> Pl
On Fri, Dec 08, 2017 at 11:06:43AM +, Paul Durrant wrote:
>> -Original Message-
>> From: Chao Gao [mailto:chao@intel.com]
>> Sent: 07 December 2017 06:57
>> To: Paul Durrant
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Andrew Cooper ; Tim
>
On Tue, Dec 12, 2017 at 09:07:46AM +, Paul Durrant wrote:
>> -Original Message-
>[snip]
>>
>> Hi, Paul.
>>
>> I merged the two qemu patches, the privcmd patch [1] and did some tests.
>> I encountered a small issue and report it to you, so you can pay more
>> attention to it when doing
On Thu, Dec 14, 2017 at 02:50:17PM +, Paul Durrant wrote:
>> -Original Message-
>> >
>> > Hmm. That looks like it is because the ioreq server pages are not owned by
>> > the correct domain. The Xen patch series underwent some changes later in
>> > review and I did not re-test my QEMU pa
On Thu, Dec 14, 2017 at 05:41:37PM +, Paul Durrant wrote:
>A subsequent patch will introduce a new scheme to allow an emulator to
>map ioreq server pages directly from Xen rather than the guest P2M.
>
>This patch lays the groundwork for that change by deferring mapping of
>gfns until their valu
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 rel
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:37AM +0100,
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
__
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
Review
hange 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
i->mc')
as I am 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
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
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
atch 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 (16):
microcode/intel: extend microcode_update_match()
microcode/amd:
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
---
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
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 ->
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
. 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
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, 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 at 08:21:39A
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 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 Wed, Sep 18, 2019 at 02:16:13PM -0700, Joe Jin wrote:
>On 9/16/19 11:48 PM, Jan Beulich wrote:
>> On 17.09.2019 00:20, Joe Jin wrote:
>>> On 9/16/19 1:01 AM, Jan Beulich wrote:
On 13.09.2019 18:38, Joe Jin wrote:
> On 9/13/19 12:14 AM, Jan Beulich wrote:
>> On 12.09.2019 20:03, Joe
stored into the patch cache.
Note that calling ->apply_microcode() itself doesn't require any
lock being held. But the parameter passed to it may be protected
by some locks. E.g. microcode_update_cpu() acquires microcode_mutex
to avoid microcode_cache being updated by others.
Signed-off-
s
- 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 (7):
microcode: split out apply_microcode() from cpu
, 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é
Reviewed-by: Jan Beulich
---
Changes in v11:
- correct parameter type
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
itmap to reduce the
number of comparison.
Signed-off-by: Chao Gao
---
Alternatively, we can mask the thread id off apicid and use it
as the unique core id. It needs to introduce new field in cpuinfo_x86
to record the mask for thread id. So I don't take this way.
---
xen/arch/x86/microcode.c
gered). The side effect is
control thread might be handling an NMI and interacting with the old
ucode not in a controlled way while other threads are loading ucode.
Update ucode on the control thread first to mitigate this issue.
Signed-off-by: Sergey Dyasli
Signed-off-by: Chao Gao
---
Changes i
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
Reviewed-by: Jan Beulich
---
Chang
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
On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote:
>On 26.09.2019 15:53, Chao Gao wrote:
>> @@ -105,23 +110,42 @@ void __init microcode_set_module(unsigned int idx)
>> }
>>
>> /*
>> - * The format is '[|scan]'. Both options are optional.
On Fri, Sep 27, 2019 at 03:55:00PM +0200, Jan Beulich wrote:
>On 27.09.2019 15:53, Chao Gao wrote:
>> On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote:
>>> On 26.09.2019 15:53, Chao Gao wrote:
>>>> @@ -420,14 +498,23 @@ static int control_thread_fn(cons
n the
control thread first to mitigate this issue.
Signed-off-by: Sergey Dyasli
Signed-off-by: Chao Gao
---
Note:
I plan to finish remaining patches (like handling parked CPU,
BDF90 and WBINVD, IMO, not important as this one) in RCs.
So this v12 only has one patch.
Changes in v12:
- take care that
er to pci_dev_wait() in linux kernel for more
detail). Here, don't assume msix capability is always visible and
return -EAGAIN to the caller.
Signed-off-by: Chao Gao
---
I didn't find a way to trigger the assertion in normal usages.
It is found by an internal test: echo 1 to /sys/bus/pci//reset
On Fri, Sep 27, 2019 at 01:19:16PM +0200, Jan Beulich wrote:
>On 26.09.2019 15:53, Chao Gao wrote:
>> If a core with all of its thread being parked, late ucode loading
>> which currently only loads ucode on online threads would lead to
>> differing ucode revisions in t
On Mon, Sep 30, 2019 at 11:09:58AM +0200, Roger Pau Monné wrote:
>On Mon, Sep 30, 2019 at 05:24:31AM +0800, Chao Gao wrote:
>> Current, Xen isn't aware of device reset (initiated by dom0). Xen may
>> access the device while device cannot respond to config requests
>> no
On Mon, Sep 30, 2019 at 11:18:05AM +0200, Jan Beulich wrote:
>On 29.09.2019 23:24, Chao Gao wrote:
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -1265,7 +1265,13 @@ int pci_msi_conf_write_intercept(struct pci_dev
>> *pdev, unsigned int reg,
>
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 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?
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
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
'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
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:
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
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 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 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: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 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 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
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]
>>
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.
>
>> ---
>>
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
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
The output of lscpu is:
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):8
On-line CPU(s) list: 0-7
Thread(s) per core:2
Core(s) per socket:4
Socket(s): 1
NUMA node(s): 1
Vendor ID:
On Tue, Jan 15, 2019 at 09:18:25AM +0100, Roger Pau Monné wrote:
>On Tue, Jan 15, 2019 at 04:04:40PM +0800, Chao Gao wrote:
>[...]
>> (XEN) Xen version 4.12-unstable (root@) (gcc (Ubuntu 7.3.0-27ubuntu1~18.04)
>> 7.3.0) debug=y Tue Jan 15 07:25:29 UTC 2019
>> (XEN) Late
Also clean up current code by moving initialization of arch specific
fields out of common code.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
Changes in v5:
- rename init_arch_msix to arch_init_msix
- place arch_init_msix right after the definition of
msi while the memory decoding
of the device is disabled. Performing a device reset without proper method
to avoid guest's MSI-X operation would lead to this issue.
The fix is basic - detach pci device before resetting the device.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
Acked-by:
s.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html
Signed-off-by: Chao Gao
---
Changes in v5:
- fix the potential infinite loop
- assert that unmap_domain_pirq() won't fail
- assert msi_list is empty after the loop in pci_unmap_msi
- provide a stub for pt_irq_destroy_bind_ms
On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> th
On Wed, Jan 16, 2019 at 01:34:28PM +0100, Roger Pau Monné wrote:
>On Wed, Jan 16, 2019 at 07:59:44PM +0800, Chao Gao wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>> >> diff -
On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> th
On Tue, Jan 22, 2019 at 01:24:48AM -0700, Jan Beulich wrote:
>>>> On 22.01.19 at 06:50, wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>>>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>>>> @@ -1529,6 +1591,8 @@ int de
On Tue, Jan 22, 2019 at 10:18:55AM +0100, Roger Pau Monné wrote:
>On Tue, Jan 22, 2019 at 01:50:20PM +0800, Chao Gao wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>> >On Wed, Jan 16, 2019 at 04:17:30PM +08
msi while the memory decoding
of the device is disabled. Performing a device reset without proper method
to avoid guest's MSI-X operation would lead to this issue.
The fix is basic - detach pci device before resetting the device.
Signed-off-by: Chao Gao
Reviewed-by: Roger Pau Monné
Acked-by:
Also clean up current code by moving initialization of arch specific
fields out of common code.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
Changes in v5:
- rename init_arch_msix to arch_init_msix
- place arch_init_msix right after the definition of
qemu/pciback can clear these flags and free the pirq.
[1]: https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html
Signed-off-by: Chao Gao
---
Changes in v6:
- introduce flags to denote that a pirq has been forcibly unmapped/unbound.
It helps to keep compatibility with c
1 - 100 of 353 matches
Mail list logo
