It was used to free the "mc" field to avoid memory leak.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c| 71 +++-
xen/arch/x86/microcode_amd.c| 80 ++---
xen/arch/x86/microcode_intel.c | 27 +++--
This check has been done in microcode_sanity_check(). Needn't do it
again in get_matching_microcode().
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode_intel.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index 96
atched ucode patch from the global cache.
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
---
Changes in v5:
- reword the commit description
- find_patch() and save_patch() are abstracted into comm
;t be called by
cpu_request_microcode() now, svm_host_osvw_init() is also moved to the
end of apply_microcode().
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c | 80 +-
xen/arch/x86/microcode_amd.c | 23 +++-
xen/arch/x86/microcode_intel.c
tem 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 (8):
microcode/intel: remove redundent check against ucode size
microcode/intel: exte
svm_host_osvm_init() (for AMD
only) are still processed sequentially.
Signed-off-by: Chao Gao
---
Changes in v5:
- newly add
---
xen/arch/x86/microcode.c | 51 ++
xen/arch/x86/microcode_amd.c | 9 +---
xen/arch/x86/microcode_intel.c | 9 +--
On Fri, Jan 25, 2019 at 10:36:13AM +0100, Roger Pau Monné wrote:
>Thanks for the patch!
>
>On Fri, Jan 25, 2019 at 04:26:59PM +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
Pau Monné wrote:
>>>>>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>>>>>> @@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg, u8
>>>>>> bus,
>> u8 devfn)
>>>>>> if ( !pdev )
>>>
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
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:
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
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 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
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
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
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
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 Fri, Dec 21, 2018 at 03:13:50AM -0700, Jan Beulich wrote:
On 20.12.18 at 16:29, wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1514,6 +1514,55 @@ static int assign_device(struct domain *d, u16 seg,
>> u8 bus, u8 devfn, u32 flag)
>> return
s.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html
Signed-off-by: Chao Gao
---
Changes in v4:
- split out change to 'msix->warned' field
- handle multiple msi cases
- use list_first_entry_or_null to traverse 'pdev->msi_list'
---
xen/drivers/passthrough/io.c |
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é
---
too
Also clean up current code by moving initialization of arch specific
fields out of common code.
Signed-off-by: Chao Gao
---
Changes in v4:
- newly added
---
xen/drivers/passthrough/pci.c | 2 +-
xen/include/asm-x86/msi.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff
On Thu, Dec 20, 2018 at 10:29:14AM +0100, Roger Pau Monné wrote:
>On Thu, Dec 20, 2018 at 10:46:29AM +0800, Chao Gao wrote:
>> On Wed, Dec 19, 2018 at 09:57:51AM +0100, Roger Pau Monné wrote:
>> >On Tue, Dec 18, 2018 at 10:43:37PM +0800, Chao Gao wrote:
>> >> I fin
On Wed, Dec 19, 2018 at 09:57:51AM +0100, Roger Pau Monné wrote:
>On Tue, Dec 18, 2018 at 10:43:37PM +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, Dec 19, 2018 at 10:00:49AM +0100, Roger Pau Monné wrote:
>On Tue, Dec 18, 2018 at 10:43:38PM +0800, Chao Gao wrote:
>> When I destroyed a guest with 'xl destroy', I found the warning
>> in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)&quo
guest later. Then guests cannot
>> receive MSIs from this device.
>>
>> To fix this issue, a pirq is unmapped before memory decoding is disabled by
>> pciback. Specifically, when a device is detached from a guest, all
>> established
>> mappings between pir
s.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html
Signed-off-by: Chao Gao
---
Applied this patch, qemu would report the error below:
[00:05.0] msi_msix_disable: Error: Unbinding of MSI-X failed. (err: 1,
pirq: 302, gvec: 0xd5)
[00:05.0] msi_msix_disable: Error: Unbinding of MS
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
---
tools/libxl/libxl_pci.c | 10
Jan Beulich wrote:
>>>>>>>> On 12.12.18 at 08:06, wrote:
>>>>>> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>>>>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>>>>>>>> On Wed, Dec 05, 2018 at 10:19
Ostrovsky wrote:
>>>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>>>>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>>>>>>> I find some pass-thru devices don't work any more across guest reboot.
>>>>>>> A
On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
>>>> On 12.12.18 at 08:06, wrote:
>> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800,
On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>>> I find some pass-thru devices don't work any more across guest reboot.
>>> Assigning it to a
On Tue, Dec 11, 2018 at 10:01:11AM -0700, Jan Beulich wrote:
On 28.11.18 at 06:34, wrote:
>> This patch ports microcode improvement patches from linux kernel.
>>
>> Before you read any further: the early loading method is still the
>> preferred one and you should always do that. The followin
Guests cannot
>> receive interrupts from this device.
>>
>> To fix this, host_maskall flag is cleared when all MSIs of a device are
>> freed.
>> It is definitely safely to clear it because no msi is actually set up
>> for this device. Also, 'msix->warned&#x
On Wed, Dec 05, 2018 at 10:32:23AM +0100, Roger Pau Monné wrote:
>On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest reboot.
>> Assigning it to another guest also meets the same issue. And the only
&g
On Tue, Dec 04, 2018 at 10:39:03PM +, Woods, Brian wrote:
>On Thu, Nov 29, 2018 at 10:22:10AM +0100, Roger Pau Monné wrote:
>> On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
>> > On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>> > >
ect.org/archives/html/xen-devel/2017-09/
msg02520.html
[2]: https://lists.xen.org/archives/html/xen-devel/2018-11/msg01616.html
Signed-off-by: Chao Gao
---
drivers/xen/xen-pciback/pci_stub.c | 49 ++
drivers/xen/xen-pciback/pciback.h | 1 +
drivers/xen/xe
On Thu, Nov 29, 2018 at 10:56:53AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 29, 2018 at 12:43:25PM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 04:22:09PM +0100, Roger Pau Monné wrote:
>> >On Wed, Nov 28, 2018 at 01:34:16PM +0800, Chao Gao wrote:
>> >> This pat
On Thu, Nov 29, 2018 at 10:46:05AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 29, 2018 at 12:28:46PM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 04:02:25PM +0100, Roger Pau Monné wrote:
>> >On Wed, Nov 28, 2018 at 01:34:14PM +0800, Chao Gao wrote:
>> >> diff --
On Thu, Nov 29, 2018 at 10:22:10AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>> >On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
>> >> .
On Wed, Nov 28, 2018 at 04:22:09PM +0100, Roger Pau Monné wrote:
>On Wed, Nov 28, 2018 at 01:34:16PM +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 Wed, Nov 28, 2018 at 04:02:25PM +0100, Roger Pau Monné wrote:
>On Wed, Nov 28, 2018 at 01:34:14PM +0800, Chao Gao wrote:
>> cpu_request_microcode() will only parse microcode file and save
>> suitable microcodes to microcode_cache. To update microcode,
>> apply_microcod
On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
>> ... and search caches to find a suitable one when loading.
>
>Why do you need to save all of them? You are only going to load a
>single microcode, so
On Wed, Nov 28, 2018 at 11:58:06AM +0100, Roger Pau Monné wrote:
>On Wed, Nov 28, 2018 at 01:34:11PM +0800, Chao Gao wrote:
>> to a more generic function. The benefit is that this function can be
>> used to check whether a microcode is newer than another as well. We
>> rel
u tasklet
> - XEN-28
> - Konrad Rzeszutek Wilk
>
>* Improvements to domain creation (v2)
> - Andrew Cooper
>
>* Argo (inter-VM communication)
> - Christopher Clark
>
>* Make credit2 scheduler the default
> - George Dunlap
>
>=== x86 ===
>
>*
Microcode pointer and size is passed to other cpu to parse microcode
locally. Now, parsing microcode is done on one CPU. Others just
find a suitable microcode stored in microcode_cache.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c | 13 ++---
1 file changed, 6 insertions(+), 7
... and search caches to find a suitable one when loading.
With this cache, the existing 'uci->mc' structure is redundent.
I deliberately avoid touching 'uci->mc' as I am going to remove
it completely in the next patch.
Signed-off-by: Chao Gao
---
xen/arch/x86/micr
-off-by: Chao Gao
---
xen/arch/x86/microcode_intel.c | 57 +++---
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index 9657575..8d9a3b2 100644
--- a/xen/arch/x86/microcode_intel.c
apply_microcode() now uses the cached microcode rather than
the microcode stored in "mc" field of ucode_cpu_info. Also remove
'microcode_resume_match' from microcode_ops because the check is
done in find_patch() in apply_microcode() callback.
Signed-off-by: Chao Gao
---
xen/
do a microcode update and online all
offlined CPUs via 'xen-hptool'.
For your convenience, you can also find this series at:
https://github.intel.com/chaogao/xen
Chao Gao (6):
microcode/intel: extend microcode_update_match()
microcode: save all microcodes which pass sanity
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
ed by
cpu_request_microcode() now, svm_host_osvw_init() is also moved to the
end of apply_microcode().
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c | 58 ++
xen/arch/x86/microcode_amd.c | 15 +--
xen/arch/x86/microcode_intel.c | 5 +-
On Mon, Nov 19, 2018 at 05:55:08AM -0700, Jan Beulich wrote:
On 19.11.18 at 13:45, wrote:
>> Another solution came to my mind:
>>
>> The intention of Xen setting 'host_maskall' is to mask a single vector. How
>> about converting the host_maskall to mask all vectors when Xen tries to init
>>
On Fri, Nov 16, 2018 at 03:30:11PM +0100, Roger Pau Monné wrote:
>On Fri, Nov 16, 2018 at 02:59:41AM -0700, Jan Beulich wrote:
>> >>> On 16.11.18 at 10:35, wrote:
>> > On Fri, Nov 16, 2018 at 03:53:50PM +0800, Chao Gao wrote:
>> >> On Thu, Nov 15, 2018 at
On Thu, Nov 15, 2018 at 11:40:39AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 15, 2018 at 09:10:26AM +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
warnings missing for Dom0.
[1]: https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html
Signed-off-by: Chao Gao
---
xen/arch/x86/msi.c| 18 ++
xen/drivers/passthrough/pci.c | 1 +
2 files changed, 19 insertions(+)
diff --git a/xen/arch/x86/msi.c
atch is also in accord with Andrew's suggestion,
>"Rendezvous all online cpus in an IPI to apply the patch, and keep the
>processors in until all have completed the patch.", in [1].
>
>[1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_up
On Fri, Nov 09, 2018 at 02:14:04AM -0700, Jan Beulich wrote:
On 09.11.18 at 01:11, 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
>> the only way to make it work again is un-binding and binding
et and MSI-x maskall bit is
updated. Also 'msix->warned' is initialized to DOMID_INVALID to avoid
warnings missing for Dom0.
[1]: https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html
Signed-off-by: Chao Gao
---
xen/drivers/passthrough/pci.c | 21
On Mon, Oct 15, 2018 at 01:06:12PM +0100, Andrew Cooper wrote:
>On 15/10/18 11:30, Roger Pau Monné wrote:
>> Hello,
>>
>> Wei recently discovered an issue when running a Linux PVH Dom0 on a
>> box with a Intel Family 6 (0x6), Model 158 (0x9e), Stepping 9 (raw
>> 000906e9) CPU, we are not sure wheth
I'd vector and
>original SVI don't match.
>
>Signed-off-by: Jan Beulich
After correcting the description in the first paragraph
Reviewed-by: Chao Gao
I am curious about in which case, the EOI'd vector differs from original SVI.
The sole caller of vmx_handle_eoi() is vl
On Fri, Jul 13, 2018 at 09:03:01PM +0100, Andrew Cooper wrote:
>This series introduces libx86, a small shared library between the hypervisor
>and libxc, and hypercalls to get full CPUID/MSR policies. Future work will
>implement XEN_DOMCTL_set_cpumsr_policy, after the auditing and comparison
>logic
On Fri, Jul 13, 2018 at 09:03:14PM +0100, Andrew Cooper wrote:
>From: Sergey Dyasli
>
>This finally (after literally years of work!) marks the point where the
>toolstack can ask the hypervisor for the current CPUID configuration of a
>specific domain.
>
>Also extend xen-cpuid's --policy mode to be
On Fri, May 18, 2018 at 03:21:14PM +0800, Chao Gao wrote:
>On Wed, May 16, 2018 at 07:46:48AM -0600, Jan Beulich wrote:
>>>>> On 16.05.18 at 15:25, wrote:
>>> On 16/05/18 14:10, Jan Beulich wrote:
>>>>> +static int do_microcode_update(void *_info)
>&
On Wed, May 16, 2018 at 07:46:48AM -0600, Jan Beulich wrote:
On 16.05.18 at 15:25, wrote:
>> On 16/05/18 14:10, Jan Beulich wrote:
+static int do_microcode_update(void *_info)
+{
+struct microcode_info *info = _info;
+unsigned int cpu = smp_processor_id();
+
Mainly for the patch behind which relies on 'nr_phys_cpus' to estimate
the time needed for microcode update in the worst case.
Signed-off-by: Chao Gao
---
v3:
- new
---
xen/arch/x86/smpboot.c| 13 +
xen/include/asm-x86/smp.h | 3 +++
2 files changed, 16 insertion
patch, and keep the
processors in until all have completed the patch.", in [1].
[1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates
Signed-off-by: Chao Gao
Tested-by: Chao Gao
[linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff
On Mon, Apr 30, 2018 at 09:25:26AM -0600, Jan Beulich wrote:
On 25.04.18 at 13:46, wrote:
>> @@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf,
>> size_t size)
>> return err;
>> }
>>
>> -static long do_microcode_update(void *_info)
>> +/* Wait for all CPUs to rend
an IPI to apply the patch, and keep the
processors in until all have completed the patch.", in [1].
[1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates
Signed-off-by: Chao Gao
Tested-by: Chao Gao
[linux commit: a5321aec6412b20b5ad15db2d6b916c05
On Mon, Apr 23, 2018 at 10:04:56AM -0600, Jan Beulich wrote:
On 08.01.18 at 05:01, wrote:
>> --- a/xen/include/asm-x86/hvm/domain.h
>> +++ b/xen/include/asm-x86/hvm/domain.h
>> @@ -213,6 +213,9 @@ struct hvm_domain {
>> uint8_t thread_per_core;
>> };
>>
>> +#define hvm_vcpu_x2apic_id(
On Mon, Apr 23, 2018 at 10:12:22PM +0800, Chao Gao wrote:
>On Mon, Apr 23, 2018 at 08:26:59AM +, Lars Kurth wrote:
>>Hi all,
>>so it seems we have no perfect slot proposals, but 2 semi-perfect.
>>May 2nd: 16:00 - 17:00 Christopher can't attend
>>May 2nd: 17:00 -
On Mon, Apr 23, 2018 at 08:26:59AM +, Lars Kurth wrote:
>Hi all,
>so it seems we have no perfect slot proposals, but 2 semi-perfect.
>May 2nd: 16:00 - 17:00 Christopher can't attend
>May 2nd: 17:00 - 18:00 Chao can't attend
>Maybe a compromise would be 16:30 to 17:30
Hi Lars,
Your suggestion
On Mon, Apr 16, 2018 at 04:26:09AM -0600, Jan Beulich wrote:
On 16.04.18 at 08:20, wrote:
>> On Fri, Apr 13, 2018 at 09:49:17AM -0600, Jan Beulich wrote:
>> On 30.03.18 at 08:59, wrote:
+static int do_microcode_update(void *_info)
+{
+struct microcode_info *info = _inf
On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote:
On 06.12.17 at 08:50, wrote:
>> Each vcpu of hvm guest consumes at least one shadow page. Currently, only 256
>> (for hap case) pages are pre-allocated as shadow memory at beginning. It
>> would
>> run out if guest has more than 25
On Wed, Apr 18, 2018 at 02:38:48AM -0600, Jan Beulich wrote:
On 06.12.17 at 08:50, wrote:
>> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software"
>> has the following description:
>>
>> "The ACPI interfaces for the x2APIC are described in Section 5.2, “ACPI
>> System
>>
On Fri, Apr 13, 2018 at 09:49:17AM -0600, Jan Beulich wrote:
On 30.03.18 at 08:59, wrote:
>> @@ -281,24 +287,52 @@ static int microcode_update_cpu(const void *buf,
>> size_t size)
>> return err;
>> }
>>
>> -static long do_microcode_update(void *_info)
>> +static int __wait_for_cpus(a
On Thu, Apr 12, 2018 at 09:29:34AM -0700, Raj, Ashok wrote:
>On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote:
>> From: Gao Chao
>>
>> This patch is to backport microcode improvement patches from linux
>> kernel. Below are the original patches des
Ping...
Can someone help to review these two patches?
On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote:
>From: Gao Chao
>
>This patch is to backport microcode improvement patches from linux
>kernel. Below are the original patches description:
&
c.info/?l=xen-devel&m=
>v4 posted by Chao Gao: https://xen.markmail.org/thread/wfyorbn3nzsio6s
>**Seems to have had review by Roger Pau Monne (1 ACK)
>No issues**
>Primarily needs George as reviewer
>Agreed to park this, because NVDIMM work is more important
I want to clarify
On Mon, Apr 09, 2018 at 07:40:15AM -0600, Jan Beulich wrote:
On 09.04.18 at 15:16, wrote:
>> Given that parsing parameters starts at very early stage in which xmalloc is
>> unusable, I choose to continue using an array other than a list to store
>> SBDFs
>> of such kind devices, like the way
specify a list of devices. For those devices, Xen doesn't
control the access right to pages where PBA resides. Hence, guest device
driver is able to write those pages and functions well. Note that adding an
untrusted device to this option may endanger security of the entire system.
Signed-off-by:
7AM +0100, George Dunlap wrote:
>>>>> On 04/05/2018 10:34 AM, Roger Pau Monné wrote:
>>>>>> On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>>>>>>> ... the same page with other registers which are not relevant to MSI-X.
>>>>>
On Thu, Apr 05, 2018 at 12:25:26PM +0100, Roger Pau Monné wrote:
>On Thu, Apr 05, 2018 at 07:00:41PM +0800, Chao Gao wrote:
>> On Thu, Apr 05, 2018 at 10:34:39AM +0100, Roger Pau Monné wrote:
>> >On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> >> diff --
On Thu, Apr 05, 2018 at 10:34:39AM +0100, Roger Pau Monné wrote:
>On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> ... the same page with other registers which are not relevant to MSI-X. Xen
>> marks pages where PBA resides as read-only. When assigning such devices to
&
On Wed, Apr 04, 2018 at 04:45:32PM +0100, Roger Pau Monné wrote:
>On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> ... the same page with other registers which are not relevant to MSI-X. Xen
>> marks pages where PBA resides as read-only. When assigning such devices to
&
specify a list of devices. For those devices, Xen doesn't
control the access right to pages where PBA resides. Hence, guest device
driver is able to write those pages and functions well. Note that adding an
untrusted device to this option may endanger security of the entire system.
Signed-off-by:
On Fri, Mar 30, 2018 at 02:23:13AM -0600, Jan Beulich wrote:
>>>> Chao Gao 03/30/18 7:19 AM >>>
>>I met an EPT violation and then the guest was destroyed by Xen
>>after assigning a device to the guest. After some investigation, I found
>>it is caused by
1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates
Signed-off-by: Chao Gao
Cc: Kevin Tian
Cc: Jun Nakajima
Cc: Ashok Raj
Cc: Borislav Petkov
Cc: Thomas Gleixner
---
xen/arch/x86/microcode.c | 89 +++-
-off-by: Chao Gao
Cc: Kevin Tian
Cc: Jun Nakajima
Cc: Ashok Raj
Cc: Borislav Petkov
Cc: Thomas Gleixner
---
xen/arch/x86/microcode.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index
Hi,
I met an EPT violation and then the guest was destroyed by Xen
after assigning a device to the guest. After some investigation, I found
it is caused by the device isn't a standard PCI device -- its MSI-x PBA
locates in the same 4k-byte page with other CSR. When the driver in
guest writes the r
On Thu, Mar 01, 2018 at 12:37:57AM -0700, Jan Beulich wrote:
>>>> Chao Gao 03/01/18 7:34 AM >>>
>>On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote:
>>>Again - here we're talking about implementation limits, not
>>>bottlenecks. So in thi
On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote:
>>>> On 26.02.18 at 14:11, wrote:
>> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
>>>>>> On 23.02.18 at 19:11, wrote:
>>>> On Wed, Dec 06, 2017 at 03:50:14PM +080
On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
>>>> On 23.02.18 at 19:11, wrote:
>> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>>> Signed-off-by: Chao Gao
>>> ---
>>> xen/include/public/hvm/hvm_info_table.h | 2 +-
&g
On Mon, Feb 26, 2018 at 01:28:07AM -0700, Jan Beulich wrote:
>>>> On 24.02.18 at 06:49, wrote:
>> On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote:
>>>On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote:
>>>> Intel SDM Extended XAPI
On Fri, Feb 23, 2018 at 06:11:39PM +, Roger Pau Monné wrote:
>On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>> Signed-off-by: Chao Gao
>> ---
>> xen/include/public/hvm/hvm_info_table.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
&
On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote:
>On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote:
>> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software"
>> has the following description:
>>
>> "The AC
On Mon, Feb 12, 2018 at 03:38:07PM +, Roger Pau Monné wrote:
>On Fri, Nov 17, 2017 at 02:22:28PM +0800, Chao Gao wrote:
>> ... handlding guest's invalidation request.
>>
>> To support pirq migration optimization and using VT-d posted interrupt to
>> inject msi
201 - 300 of 353 matches
Mail list logo
