Hi Julien
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2019年1月29日 23:57
> To: Peng Fan ; sstabell...@kernel.org; jgr...@suse.com
> Cc: xen-devel@lists.xenproject.org; Andre Przywara
>
> Subject: Re: [PATCH for-4.12] arm: gic: deactivate sgi immediately a
flight 132561 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132561/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-install fail REGR. vs. 132451
test-armhf-armhf-ex
flight 132567 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
129475
test-amd64-i386-xl-qemu
flight 132495 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132495/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-examine 4 memdisk-try-append fail like 132136
test-amd64-amd64-xl-qemuu-dmrestrict-am
flight 132551 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132551/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 13184
On 23/01/2019 11:35, Jan Beulich wrote:
On 21.01.19 at 16:37, wrote:
>> --- a/xen/arch/x86/guest/pvh-boot.c
>> +++ b/xen/arch/x86/guest/pvh-boot.c
>> @@ -38,12 +38,20 @@ static const char *__initdata pvh_loader = "PVH
>> Directboot";
>> static void __init convert_pvh_info(multiboot_info_t *
flight 132486 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130860
Tests which di
flight 132472 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 132451
test-amd64-amd64-exa
Hello,
Given the following vm.cfg file:
name="vm"
type="hvm"
vcpus=4
memory=1024
firmware_override="/root/xen-syms"
kernel="/boot/vmlinuz-4.4-xen"
ramdisk="/boot/initrd-4.4.0+10.img"
cmdline="console=xen,pv dom0=pv --- earlyprintk=xen"
Xen crashes with the following trace:
(d15) (XEN) Xen B
When booting a guest using "pvshim=1" in the VM configuration file, libxl's
default command line is "pv-shim console=xen,pv".
With a CONFIG_PV_SHIM_EXCLUSIVE hypervisor, the boolean_param() is compiled
out, resulting in a command line parsing warning:
(d8) [ 1556.334664] (XEN) parameter "pv-shi
Hi Oleksandr,
On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend
On 29/01/2019 18:49, osstest service owner wrote:
> flight 132484 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/132484/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-1 69
flight 132484 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130954
test-amd64-i386
flight 132456 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 128858
test-amd64-amd64-xl-
flight 132468 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
test-amd64-amd64-xl-
flight 132569 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132569/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 132544 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132544/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16
guest-localmigrate/x10 fail REGR. vs. 13
Hi Andrii,
On 29/01/2019 16:00, Andrii Anisov wrote:
On 29.01.19 17:17, Julien Grall wrote:
They have been lucky to see this working even on baremetal.
Set/Way operations have been dropped from Linux for a long time, so I really
can't see why a proprietary driver is still using them.
I guess
On 29.01.19 17:34, Julien Grall wrote:
Andrii, please try to add the subsystem you modify in the commit title (i.e
xen/arm). This helps for the reviewer to know what you are modifying and also
helps when looking at shortlog.
Oh, I missed "arm/" this time.
Will try to not miss it further.
--
On 29.01.19 17:17, Julien Grall wrote:
No we don't have to.
I mean, EPAM systems as a XEN based virtualization solution provider have to
handle that issue.
They have been lucky to see this working even on baremetal.
Set/Way operations have been dropped from Linux for a long time, so I really
(+ Andre)
Hi Peng,
On 24/01/2019 12:43, Peng Fan wrote:
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because we also need to support A72 Cluster reboot without
affecting A53 Cluster.
How
>>> On 29.01.19 at 16:02, wrote:
> On Thu, Dec 13, 2018 at 07:47:59AM -0700, Jan Beulich wrote:
>> >>> On 13.12.18 at 15:20, wrote:
>> > On Thu, Dec 13, 2018 at 03:17:05AM -0700, Jan Beulich wrote:
>> >> >>> On 13.12.18 at 10:14, wrote:
>> >> > On Thu, Dec 13, 2018 at 12:45:07AM -0700, Jan Beuli
Hi,
On 28/01/2019 12:04, Juergen Gross wrote:
On 25/01/2019 18:06, Andrii Anisov wrote:
From: Andrii Anisov
Currently, that assert condition does not correspond to a comment above
and makes assertion failed on HW IRQ disconnection.
Fix the condition so it corresponds to the comment and allows
Hi,
On 28/01/2019 22:58, Stefano Stabellini wrote:
On Mon, 28 Jan 2019, Julien Grall wrote:
Hi,
On 1/26/19 1:30 AM, Stefano Stabellini wrote:
On Mon, 21 Jan 2019, Julien Grall wrote:
Hi,
Ping?
Cheers,
On 30/11/2018 17:25, Julien Grall wrote:
Hi,
Below a list of backport candidate for Ar
Hi Andrii,
On 29/01/2019 14:33, Andrii Anisov wrote:
On 29.01.19 15:53, Julien Grall wrote:
Using Set/Way is fundamentally broken partly because it does not deal with
system caches.
I already know it. I've looked at KVM presentation from 2015, your last year
video from China, reading through A
On 29/01/2019 13:43, Ian Jackson wrote:
> Juergen Gross writes ("OSStest commits and Xen releases"):
>> I have found an alarming tendency regarding changes in the OSStest
>> repository: over the last 2 years (or 3 Xen versions) there has been
>> a pattern of OSStest commits being more frequent duri
>>> On 29.01.19 at 14:47, wrote:
> On 1/29/19 10:46, Jan Beulich wrote:
> Norbert Manthey 01/29/19 9:35 AM >>>
>>> I am aware that both version use the same base array, and access it via
>>> different macros, which essentially partition the array based on the
>>> size of the respective struct
From: Oleksandr Andrushchenko
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and backend which may cause screen artifacts.
Fixes: c575b7eeb89f
On Thu, Dec 13, 2018 at 07:47:59AM -0700, Jan Beulich wrote:
> >>> On 13.12.18 at 15:20, wrote:
> > On Thu, Dec 13, 2018 at 03:17:05AM -0700, Jan Beulich wrote:
> >> >>> On 13.12.18 at 10:14, wrote:
> >> > On Thu, Dec 13, 2018 at 12:45:07AM -0700, Jan Beulich wrote:
> >> >> >>> On 12.12.18 at 18:
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>>> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Hello, Julien!
>>>
>>> Hi,
>>>
On 1/21/19 7:09 PM, Julie
The get_page_from_gfn method returns a pointer to a page that belongs
to a gfn. Before returning the pointer, the gfn is checked for being
valid. Under speculation, these checks can be bypassed, so that
the function get_page is still executed partially. Consequently, the
function page_get_owner_and
Guests can issue grant table operations and provide guest controlled
data to them. This data is also used for memory loads. To avoid
speculative out-of-bound accesses, we use the array_index_nospec macro
where applicable. However, there are also memory accesses that cannot
be protected by a single
Checks of domain properties, such as is_hardware_domain or is_hvm_domain,
might be bypassed by speculatively executing these instructions. A reason
for bypassing these checks is that these macros access the domain
structure via a pointer, and check a certain field. Since this memory
access is slow,
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
Signed-off-by: Norbert Manthey
---
xen/include/xen/sched.h | 6 --
1 file changed, 4 i
flight 132562 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132562/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
To control the runtime behavior on L1TF vulnerable platforms better, the
command line option l1tf-barrier is introduced. This option controls
whether on vulnerable x86 platforms the lfence instruction is used to
prevent speculative execution from bypassing the evaluation of
conditionals that are pr
Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
L1 cache is problemetic, because when hyperthreading is used as well, a
guest running on the sibling core can leak this potentially secret data.
To prevent these speculative accesses, we block speculation after
accessing the
There are multiple arrays in the HVM interface that are accessed
with indices that are provided by the guest. To avoid speculative
out-of-bound accesses, we use the array_index_nospec macro.
When blocking speculative out-of-bound accesses, we can classify arrays
into dynamic arrays and static arra
When interacting with io apic, a guest can specify values that are used
as index to structures, and whose values are not compared against
upper bounds to prevent speculative out-of-bound accesses. This change
prevents these speculative accesses.
Furthermore, two variables are initialized and the c
Guests can issue event channel interaction with guest specified data.
To avoid speculative out-of-bound accesses, we use the nospec macros.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/common/event_channel.c | 25 ++--
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
On 29.01.19 15:53, Julien Grall wrote:
Which proprietary kernel driver? And in which context are Set/Way operations
used?
I would not name it, it is proprietary ;) But we can't live without it.
Using Set/Way is fundamentally broken partly because it does not deal with
system caches.
I alr
flight 132467 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132467/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
129475
test-amd64-i386-xl-qemu
On Tue, Jan 29, 2019 at 08:11:33PM +0800, Chao Gao wrote:
> 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)
> >> - Addr
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't parse the microcode blo
On 29/01/2019 13:36, Andrii Anisov wrote:
Hello Julien,
Hi,
On 28.01.19 18:54, Julien Grall wrote:
There should be no Set/Way in Linux 4.14. So I am a bit confused how can
even reach this code.
Well, that is a proprietary kernel driver doing cache maintenance using Set/Way
operations. And
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,
>>struct cpu_signature *csig)
>>return 0;
>>}
> >
On 1/29/19 10:46, Jan Beulich wrote:
Norbert Manthey 01/29/19 9:35 AM >>>
>> I am aware that both version use the same base array, and access it via
>> different macros, which essentially partition the array based on the
>> size of the respective struct. The underlying raw array has the same
Following reflashing of the two machines, and recent work to change
the PDU usage, which I think will help with the reliability, I am
intending to revert this as soon as I have rerun a commissioning test
on both laxtons.
Ian.
From a7491b211f06daa8fa6e0f646bf717958cf91a2b Mon Sep 17 00:00:00 2001
Hello Julien,
On 28.01.19 18:54, Julien Grall wrote:
There should be no Set/Way in Linux 4.14. So I am a bit confused how can even
reach this code.
Well, that is a proprietary kernel driver doing cache maintenance using Set/Way
operations. And I'm not sure if we can avoid that :(
--
Sincere
Wei Liu writes ("[PATCH for-4.12] libxl: correctly dispose of dominfo list in
libxl_name_to_domid"):
> Tamas reported ssid_label was leaked. Use the designated function to
> free dominfo list to fix the leakage.
>
> Reported-by: Tamas K Lengyel
> Signed-off-by: Wei Liu
> Tested-by: Tamas K Leng
Hello Jairo,
On 29.01.19 17:30, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4800 - 7fff
(XEN) RAM: 0006 - 00063fff
(XEN) RAM: 0006 - 00063fff
Duplication of RAM range `000600
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_matching_microcode() only
>one is preceded by a ca
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 January 2019 13:05
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 4/8] viridian: add missing context save helpers
> into synic a
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 29 January 2019 12:25
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Stefan Hajnoczi ; Stefano
> Stabellini ; Kevin Wolf ; Max
> Reitz
> Subjec
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
>> --- a/xen/include/asm-x86/
>>> Paul Durrant 01/08/19 4:18 PM >>>
>Currently the time module lacks vcpu context save helpers and the synic
>module lacks domain context save helpers. These helpers are not yet
>required but subsequent patches will require at least some of them so this
>patch completes the set to avoid introduc
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,
>> we want to put the apply_microcode
Juergen Gross writes ("OSStest commits and Xen releases"):
> I have found an alarming tendency regarding changes in the OSStest
> repository: over the last 2 years (or 3 Xen versions) there has been
> a pattern of OSStest commits being more frequent during the RC phase
> of a Xen release. On averag
On Wed, Jan 23, 2019 at 09:08:49AM +, Paul Durrant wrote:
> Some frontend drivers will handle dynamic resizing of PV disks, so set up
> the BlockDevOps resize_cb() method during xen_block_realize() to allow
> this to be done.
"will": which drivers are you thinking about? The Linux one seems to
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 version.
>>
>> The intention of th
On 29/01/2019 12:37, Wei Liu wrote:
> Tamas reported ssid_label was leaked. Use the designated function to
> free dominfo list to fix the leakage.
>
> Reported-by: Tamas K Lengyel
> Signed-off-by: Wei Liu
> Tested-by: Tamas K Lengyel
Release-acked-by: Juergen Gross
Juergen
___
>>> Paul Durrant 01/08/19 4:18 PM >>>
>This patch simply adds domain and vcpu init/deinit hooks into the synic
>and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
>Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
>but subsequent patches will make
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 January 2019 11:48
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 1/8] viridian: add init hooks
>
> >>> Paul Durrant 01/08/19
>>> Paul Durrant 01/08/19 4:18 PM >>>
>--- a/xen/arch/x86/hvm/hvm.c
>+++ b/xen/arch/x86/hvm/hvm.c
>@@ -665,12 +665,18 @@ int hvm_domain_initialise(struct domain *d)
>if ( hvm_tsc_scaling_supported )
>d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio;
>
>+rc = viridian_domain_init(
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Beulich
commit fc24d75a7f91837d7918e40719575951820b2b8f upstream.
While in the native case entry into the kernel happens on the trampoline
stack, PV Xen kernels get entered with the curren
flight 132535 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 132451
test-armhf-armhf-xl
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Beulich
commit fc24d75a7f91837d7918e40719575951820b2b8f upstream.
While in the native case entry into the kernel happens on the trampoline
stack, PV Xen kernels get entered with the curren
Tamas reported ssid_label was leaked. Use the designated function to
free dominfo list to fix the leakage.
Reported-by: Tamas K Lengyel
Signed-off-by: Wei Liu
Tested-by: Tamas K Lengyel
---
Backport candidate.
---
tools/libxl/libxl_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 version.
>
> The intention of this series is to make the late microcode loading
> more reliable by rend
On Tue, Jan 29, 2019 at 04:23:55AM -0700, Jan Beulich wrote:
> >>> Wei Liu 01/18/19 1:44 PM >>>
> >Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
> >hypervisors build with grant table disabled.
> >
> >Signed-off-by: Wei Liu
>
> I continue to misinterpret the title - would
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
> parallel microcode update on cores.
Oh, that's what I missed from the previous patch then, and w
>>> Wei Liu 01/18/19 1:44 PM >>>
>Introduce CONFIG_GRANT_TABLE. Provide stubs and make sure x86 and arm
>hypervisors build with grant table disabled.
>
>Signed-off-by: Wei Liu
I continue to misinterpret the title - would you mind making it "make grant
table support configurable", to disambiguate
>>> Pu Wen 12/20/18 2:16 PM >>>
>--- a/xen/arch/x86/xstate.c
>+++ b/xen/arch/x86/xstate.c
>@@ -369,7 +369,7 @@ void xrstor(struct vcpu *v, uint64_t mask)
>unsigned int faults, prev_faults;
>
>/*
>- * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
>+ * AMD or Hygon CPUs don't
>>> Pu Wen 12/20/18 2:16 PM >>>
>--- a/xen/arch/x86/traps.c
>+++ b/xen/arch/x86/traps.c
>@@ -1973,6 +1973,8 @@ static unsigned int calc_ler_msr(void)
>return MSR_IA32_LASTINTFROMIP;
>}
>break;
>+case X86_VENDOR_HYGON:
>+return MSR_IA32_LASTINTFROMIP;
With a blank line added above your
>>> Eric DeVolder 01/14/19 8:48 PM >>>
>On April 20, 2018, I posted to xen-devel an RFC inquiring about
>support for signature verification of kexec within Xen:
>
>https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01655.html
>
>Since then, I've worked towards a solution. For the purp
>>> Eric DeVolder 01/14/19 8:49 PM >>>
>@@ -213,8 +214,9 @@ typedef struct xen_kexec_load {
>uint64_t _pad;
>} segments;
>uint64_t entry_maddr; /* image entry point machine address. */
>-} xen_kexec_load_t;
>+} xen_kexec_load_t, xen_kexec_file_load_t;
>DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);
>+
>>> Roger Pau Monné 01/29/19 11:39 AM >>>
>On Mon, Jan 28, 2019 at 03:06:49PM +0800, Chao Gao wrote:
>> +/*
>> + * Initiate an update on all processors which don't have an online
>> sibling
>> + * thread with a lower thread id. Other sibling threads just await the
>> + * completio
>>> 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, struct
>cpu_signature *csig)
>return 0;
>}
>
>-static inline int microcode_update_match(
>-unsigned int cpu_n
Hi,
On 29/01/2019 00:52, Stefano Stabellini wrote:
On Mon, 28 Jan 2019, Julien Grall wrote:
On 1/27/19 9:55 AM, Julien Grall wrote:
Hi,
On 1/25/19 9:36 PM, Stefano Stabellini wrote:
On Thu, 24 Jan 2019, Julien Grall wrote:
@James, please correct me if I am wrong below :).
On 24/01/2019 00:
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
> preferred one and you should always do that. The following patch is
> improving the late loading me
Mike Rapoport writes:
> The memblock_alloc_base() function tries to allocate a memory up to the
> limit specified by its max_addr parameter and panics if the allocation
> fails. Replace its usage with memblock_phys_alloc_range() and make the
> callers check the return value and panic in case of e
flight 132541 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132541/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132511
test-armhf-armhf-libvirt-raw 13 saveresto
>>> 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_matching_microcode() only
one is preceded by a call to microcode_sanity_check(). There's also
no visible connection
>>> Chao Gao 01/28/19 12:59 PM >>>
>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
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't parse the microcode blob; the pointer and
> size can be removed.
>
> Signed-off-by: Chao Ga
On Mon, Jan 28, 2019 at 05:57:04PM -0700, Tamas K Lengyel wrote:
> On Mon, Jan 28, 2019 at 5:16 AM Wei Liu wrote:
> >
> > On Sat, Jan 26, 2019 at 10:45:07PM -0700, Tamas K Lengyel wrote:
> > > On systems with XSM enabled libxl_name_to_domid leaks memory
> > > allocated for ssid_label:
> > >
> > >
Michael Ellerman writes:
> Mike Rapoport writes:
>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index ae34e3a..2c61ea4 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64
>> start_pfn, u64 e
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,
> we want to put the apply_microcode() into stop_machine context. So
> we split out it from cpu_request_m
Mike Rapoport writes:
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index ae34e3a..2c61ea4 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64
> start_pfn, u64 end_pfn)
> pr_info("Ini
Mike Rapoport writes:
> From: Christophe Leroy
>
> Since only the virtual address of allocated blocks is used,
> lets use functions returning directly virtual address.
>
> Those functions have the advantage of also zeroing the block.
>
> [ MR:
> - updated error message in alloc_stack() to be mo
>>> Norbert Manthey 01/29/19 9:35 AM >>>
>I am aware that both version use the same base array, and access it via
>different macros, which essentially partition the array based on the
>size of the respective struct. The underlying raw array has the same
>size for both version.
And this is the pro
On 25/01/2019 08:33, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> Putting the make invocation to produce the header tog
On 25/01/2019 08:34, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> In particular the harness has a "run" goal which is s
On 28/01/2019 17:40, Andrew Cooper wrote:
> Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
> complicated, because at that point no CPUID information had been set for the
> guest. Auditing against the host CPUID was better than nothing, but not
> ideal.
>
> Similarl
On 28/01/2019 15:22, Roger Pau Monne wrote:
> The current GSI mapping code can cause the following deadlock:
>
> (XEN) *** Dumping CPU0 host state: ***
> (XEN) [ Xen-4.12.0-rc x86_64 debug=y Tainted: C ]
> [...]
> (XEN) Xen call trace:
> (XEN)[] vmac.c#_spin_lock_cb+0x32/0x70
>
> -Original Message-
> From: h...@infradead.org [mailto:h...@infradead.org]
> Sent: 2019年1月28日 16:00
> To: Peng Fan
> Cc: h...@infradead.org; Stefano Stabellini ;
> m...@redhat.com; jasow...@redhat.com; xen-devel@lists.xenproject.org;
> linux-remotep...@vger.kernel.org; linux-ker...@vger
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
> --- a/xen/include/asm-x86/microcode.h
> +++ b/xen/include/asm-x86/microcode.h
> @@ -19,7 +19,6 @@ str
On Tue, Jan 29, 2019 at 12:41:42PM +0800, Chao Gao wrote:
> 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 benefi
On 1/28/19 16:09, Jan Beulich wrote:
On 28.01.19 at 15:45, wrote:
>> On 1/23/19 14:37, Jan Beulich wrote:
>> On 23.01.19 at 12:51, wrote:
@@ -2223,7 +2231,8 @@ gnttab_transfer(
okay = gnttab_prepare_for_transfer(e, d, gop.ref);
spin_lock(&e->page_alloc_lo
100 matches
Mail list logo
