On Thu, Jul 19, 2018 at 12:34 PM, Stefano Stabellini wrote:
> On Thu, 19 Jul 2018, Jan Beulich wrote:
> > >>> Stefano Stabellini 07/19/18 8:49 PM >>>
> > >On Thu, 19 Jul 2018, Jan Beulich wrote:
> > >> >>> Stefano Stabellini 07/19/18 7:00 PM >>>
> > >> >On Thu, 19 Jul 2018, Jan Beulich wrote:
flight 125453 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125453/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 125432
Tests which
flight 125335 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken in 125270
flight 125452 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 125295
Tests which did not
On Thu, Jul 19, 2018 at 11:37:59PM +0200, Ahmed Abd El Mawgood wrote:
> Hi,
>
> This is my first set of patches that works as I would expect, and the
> third revision I sent to mailing lists.
>
> Following up with my previous discussions about kernel rootkit mitigation
> via placing R/O
flight 125447 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125447/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 125432
Tests which
flight 125446 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125446/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
flight 125443 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
build-amd64 6
flight 125441 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
On 07/19/2018 05:39 PM, Waiman Long wrote:
> On a VM with only 1 vCPU, the locking fast paths will always be
> successful. In this case, there is no need to use the the PV qspinlock
> code which has higher overhead on the unlock side than the native
> qspinlock code.
>
> The xen_pvspin veriable is
On 07/19/2018 05:54 PM, Davidlohr Bueso wrote:
> On Thu, 19 Jul 2018, Waiman Long wrote:
>
>> On a VM with only 1 vCPU, the locking fast paths will always be
>> successful. In this case, there is no need to use the the PV qspinlock
>> code which has higher overhead on the unlock side than the
On Thu, 19 Jul 2018, Waiman Long wrote:
On a VM with only 1 vCPU, the locking fast paths will always be
successful. In this case, there is no need to use the the PV qspinlock
code which has higher overhead on the unlock side than the native
qspinlock code.
The xen_pvspin veriable is also
On a VM with only 1 vCPU, the locking fast paths will always be
successful. In this case, there is no need to use the the PV qspinlock
code which has higher overhead on the unlock side than the native
qspinlock code.
The xen_pvspin veriable is also turned off in this 1 vCPU case to
eliminate
flight 125439 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 125432
Tests which
flight 125314 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 125242
flight 125440 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
On 07/19/2018 03:18 PM, Boris Ostrovsky wrote:
> On 07/19/2018 09:48 AM, Waiman Long wrote:
>> On a VM with only 1 vCPU, the locking fast paths will always be
>> successful. In this case, there is no need to use the the PV qspinlock
>> code which has higher overhead on the unlock side than the
On Thu, 19 Jul 2018, Jan Beulich wrote:
> >>> Stefano Stabellini 07/19/18 8:49 PM >>>
> >On Thu, 19 Jul 2018, Jan Beulich wrote:
> >> >>> Stefano Stabellini 07/19/18 7:00 PM >>>
> >> >On Thu, 19 Jul 2018, Jan Beulich wrote:
> >> >> > Signed-off-by: Christopher Clark
> >> >> > ---
> >> >> >
On 07/19/2018 09:48 AM, Waiman Long wrote:
> On a VM with only 1 vCPU, the locking fast paths will always be
> successful. In this case, there is no need to use the the PV qspinlock
> code which has higher overhead on the unlock side than the native
> qspinlock code.
>
> Signed-off-by: Waiman Long
flight 125437 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
On 19/07/18 20:00, Jan Beulich wrote:
Andrew Cooper 07/19/18 8:47 PM >>>
>> On 19/07/18 19:37, Jan Beulich wrote:
> Andrew Cooper 07/19/18 1:55 PM >>>
>>> On 19/07/18 12:47, Jan Beulich wrote:
This patch feeds the PDPTE registers into the cache, which breaks the
architectural
>>> Stefano Stabellini 07/19/18 8:49 PM >>>
>On Thu, 19 Jul 2018, Jan Beulich wrote:
>> >>> Stefano Stabellini 07/19/18 7:00 PM >>>
>> >On Thu, 19 Jul 2018, Jan Beulich wrote:
>> >> > Signed-off-by: Christopher Clark
>> >> > ---
>> >> > Please use my gmail address for any correspondence to me.
>>> Andrew Cooper 07/19/18 8:47 PM >>>
>On 19/07/18 19:37, Jan Beulich wrote:
Andrew Cooper 07/19/18 1:55 PM >>>
>> On 19/07/18 12:47, Jan Beulich wrote:
>>> This patch feeds the PDPTE registers into the cache, which breaks the
>>> architectural correctness of patch 3, because the PDPTE
On 19/07/18 19:49, Stefano Stabellini wrote:
> On Thu, 19 Jul 2018, Jan Beulich wrote:
> Stefano Stabellini 07/19/18 7:00 PM >>>
>>> On Thu, 19 Jul 2018, Jan Beulich wrote:
> Signed-off-by: Christopher Clark
> ---
> Please use my gmail address for any correspondence to me.
I
On Thu, 19 Jul 2018, Jan Beulich wrote:
> >>> Stefano Stabellini 07/19/18 7:00 PM >>>
> >On Thu, 19 Jul 2018, Jan Beulich wrote:
> >> > Signed-off-by: Christopher Clark
> >> > ---
> >> > Please use my gmail address for any correspondence to me.
> >>
> >> I think it is generally considered bad
>>> Andrew Cooper 07/19/18 1:46 PM >>>
>Andrew Cooper (2):
>x86/xstate: Use a guests CPUID policy, rather than allowing all features
>x86/xstate: Make errors in xstate calculations more obvious by crashing the
>domain
Reviewed-by: Jan Beulich
___
On 19/07/18 19:37, Jan Beulich wrote:
Andrew Cooper 07/19/18 1:55 PM >>>
>> On 19/07/18 12:47, Jan Beulich wrote:
>> On 19.07.18 at 13:15, wrote:
On 19/07/18 11:50, Jan Beulich wrote:
> Since strictly speaking it is incorrect for guest_walk_tables() to read
> L3 entries
flight 125304 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125304/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
>>> Tamas K Lengyel 07/19/18 5:09 PM >>>
>On Thu, Jul 19, 2018 at 2:30 AM Jan Beulich wrote:
> >>> On 19.07.18 at 10:18, wrote:
> > On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
> >> > On Jul 2, 2018, at 8:42 AM, Alexandru Isaila > >> > +break;
>> >> > +case
>>> Andrew Cooper 07/19/18 1:55 PM >>>
>On 19/07/18 12:47, Jan Beulich wrote:
> On 19.07.18 at 13:15, wrote:
>>> On 19/07/18 11:50, Jan Beulich wrote:
Since strictly speaking it is incorrect for guest_walk_tables() to read
L3 entries during PAE page walks, try to overcome this
>>> Stefano Stabellini 07/19/18 7:00 PM >>>
>On Thu, 19 Jul 2018, Jan Beulich wrote:
>> > Signed-off-by: Christopher Clark
>> > ---
>> > Please use my gmail address for any correspondence to me.
>>
>> I think it is generally considered bad practice to have From: and S-o-b
>> differ.
>
>Why?
On 19/07/2018, 08:40, "Juergen Gross" wrote:
> **ACTION: George will put together a survey for the committers outlining
the issue and
> trade-offs and then go from there**
>
Ping? Anything new? I'd like to know the dates for 4.12...
Adding George: He was doing the
flight 125434 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125434/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
-usbdevice is deprecated as of QEMU 2.10.
This patch replace the few options documented in xl.cfg(5) by the
recommanded syntax. And if the option isn't recognize, simply use
-usbdevice with a warning, the options isn't entirely removed from QEMU
upstream.
Also, remove from the manual the
On Thu, 19 Jul 2018, Jan Beulich wrote:
> >>> On 18.07.18 at 18:59, wrote:
> > On 18/07/18 08:12, Jan Beulich wrote:
> > On 17.07.18 at 22:29, wrote:
> >>> On 07/07/2018 00:12, Stefano Stabellini wrote:
> Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> mechanism
On Thu, 19 Jul 2018, Jan Beulich wrote:
> > Signed-off-by: Christopher Clark
> > ---
> > Please use my gmail address for any correspondence to me.
>
> I think it is generally considered bad practice to have From: and S-o-b
> differ.
Why? That is perfectly fine. Signed-off-by is about copyright
flight 125432 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125432/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 12/07/18 11:24, Lars Kurth wrote:
>
>
> On 06/07/2018, 17:42, "Lars Kurth" wrote:
>
> Hi all, (I also moved the AB to BCC)
>
> I summarized the discussion in
> https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/edit?usp=sharing
>
>
> I
On Thu, Jul 19, 2018 at 2:30 AM Jan Beulich wrote:
>
> >>> On 19.07.18 at 10:18, wrote:
> > On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
> >> > On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >> > @@ -112,8 +117,37 @@ static unsigned long p2m_type_to_flags(const
> >> > struct p2m_domain
On Thu, Jul 19, 2018 at 03:30:52PM +0100, Anthony PERARD wrote:
> Fix the command to use shell syntax for environment variables.
>
> Make it more explicite that the command `make` is going to modifie the
typo: explicit and modify.
> current directory.
>
> Also include an example of what a
Fix the command to use shell syntax for environment variables.
Make it more explicite that the command `make` is going to modifie the
current directory.
Also include an example of what a container is.
Signed-off-by: Anthony PERARD
---
I'm attempted to change the short options by their long
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 July 2018 11:49
> To: xen-devel
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Paul Durrant ;
> George Dunlap ; Jun Nakajima
> ; Kevin Tian ; Boris
> Ostrovsky ; Tim (Xen.org)
> Subject:
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since v11:
- hvm_save_mtrr_msr() now returns err from hvm_save_mtrr_msr_one().
Note: This patch is based on Roger Pau Monne's series[1]
---
xen/arch/x86/hvm/mtrr.c | 81
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Removed the memset and added init with {}.
---
xen/arch/x86/cpu/mcheck/vmce.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git
This patch removes the redundant save functions and renames the
save_one* to save. It then changes the domain param to vcpu in the
save funcs.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Remove enum return type for save funcs.
---
xen/arch/x86/cpu/mcheck/vmce.c | 19
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V12:
- Changed memset to {} init.
---
xen/arch/x86/hvm/hvm.c | 214 +
1 file changed, 111 insertions(+), 103 deletions(-)
diff --git
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V11:
- hvm_save_cpu_msrs() returns err from hvm_save_cpu_msrs_one().
---
xen/arch/x86/hvm/hvm.c | 105 +++--
1 file
This patch is focused on moving the for loop to the caller so
now we can save info for a single vcpu instance with the save_one
handlers.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Changed the CONTINUE return to return 0.
---
xen/arch/x86/hvm/hvm.c | 19 ---
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Change return of the save_one func to return hvm_save_entry.
---
xen/arch/x86/hvm/hvm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- hvm_save_cpu_xsave_states_one() returns the err from
_hvm_init_entry().
- hvm_save_cpu_xsave_states() returns err from
hvm_save_cpu_xsave_states_one();
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 -
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 5 +
xen/arch/x86/hvm/i8254.c | 2 +-
xen/arch/x86/hvm/irq.c | 6 +++---
xen/arch/x86/hvm/mtrr.c| 2 +-
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V12:
- Remove blank line
- Apply coding style to for_each.
---
xen/arch/x86/hvm/viridian.c | 30 +++---
1 file changed, 19
Signed-off-by: Alexandru Isaila
---
Changes since V8:
- Add comment for the handler return values.
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 +
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 6 +-
xen/arch/x86/hvm/i8254.c | 2 +-
xen/arch/x86/hvm/irq.c
Hi all,
This patch series addresses the ideea of saving data from a single vcpu
instance.
First it starts by adding *save_one functions, then it introduces a handler for
the
new save_one* funcs and makes use of it in the hvm_save and hvm_save_one funcs.
The final 2 patches are used for clean
On a VM with only 1 vCPU, the locking fast paths will always be
successful. In this case, there is no need to use the the PV qspinlock
code which has higher overhead on the unlock side than the native
qspinlock code.
Signed-off-by: Waiman Long
---
arch/x86/xen/spinlock.c | 3 ++-
1 file
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 July 2018 11:47
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap
> Subject: [PATCH 2/6] x86/mm: use optional cache in guest_walk_tables()
>
> The caching isn't actually implemented here,
On Jo, 2018-07-19 at 04:02 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 19.07.18 at 10:43, wrote:
> > On 07/19/2018 11:30 AM, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 19.07.18 at 10:18, wrote:
> > > > On Mi, 2018-07-18 at 15:33 +, George Dunlap
flight 125300 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125300/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
flight 125407 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
On 19/07/18 12:47, Jan Beulich wrote:
On 19.07.18 at 13:15, wrote:
>> On 19/07/18 11:50, Jan Beulich wrote:
>>> Since strictly speaking it is incorrect for guest_walk_tables() to read
>>> L3 entries during PAE page walks, try to overcome this where possible by
>>> pre-loading the values from
>>> On 19.07.18 at 13:15, wrote:
> On 19/07/18 11:50, Jan Beulich wrote:
>> Since strictly speaking it is incorrect for guest_walk_tables() to read
>> L3 entries during PAE page walks, try to overcome this where possible by
>> pre-loading the values from hardware into the cache. Sadly the
>>
>>> On 19.07.18 at 13:16, wrote:
> On 07/19/2018 11:32 AM, Jan Beulich wrote:
>> Note: On one of my test systems the parked CPUs get _PSD data reported
>> by Dom0 that is different from the non-parked ones (coord_type is
>> 0xFC instead of 0xFE). Giving Dom0 enough vCPU-s eliminates
It turns out that Xen has never enforced that a domain remain within the
xstate features advertised in CPUID.
The check of new_bv against xfeature_mask ensures that a domain stays within
the set of features that Xen has enabled in hardware (and therefore isn't a
security problem), but this does
Andrew Cooper (2):
x86/xstate: Use a guests CPUID policy, rather than allowing all features
x86/xstate: Make errors in xstate calculations more obvious by crashing the
domain
xen/arch/x86/domctl.c| 2 +-
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/xstate.c| 37
If xcr0_max exceeds xfeature_mask, then something is broken with the CPUID
policy derivation or auditing logic. If hardware rejects new_bv, then
something is broken with Xen's xstate logic.
In both cases, crash the domain with an obvious error message, to help
highlight the issues.
On 19/07/18 11:50, Jan Beulich wrote:
> Since strictly speaking it is incorrect for guest_walk_tables() to read
> L3 entries during PAE page walks, try to overcome this where possible by
> pre-loading the values from hardware into the cache. Sadly the
> information is available in the EPT case
On 07/19/2018 11:32 AM, Jan Beulich wrote:
> Note: On one of my test systems the parked CPUs get _PSD data reported
> by Dom0 that is different from the non-parked ones (coord_type is
> 0xFC instead of 0xFE). Giving Dom0 enough vCPU-s eliminates this
> problem, so there is
>>> On 19.07.18 at 12:39, wrote:
> If panic is called before init_idle_domain on a tboot-launched system,
> then Xen recursively faults in write_ptbase as seen below.
>
> (XEN)[] write_ptbase+0/0x10
> (XEN)[] tboot_shutdown+0x6b/0x260
> (XEN)[] machine_restart+0xac/0x2d0
> (XEN)
Correct indentation of a piece of code, adjusting comment style at the
same time. Constify gl3e pointers and drop a bogus (and useless once
corrected) cast.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3989,9 +3989,8 @@
Since strictly speaking it is incorrect for guest_walk_tables() to read
L3 entries during PAE page walks, try to overcome this where possible by
pre-loading the values from hardware into the cache. Sadly the
information is available in the EPT case only. On the positive side for
NPT the spec
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far use of CPU
registers goes (as those can't change without any other instruction
executing in between),
Checking the low 5 bits of CR3 is not the job of vmx_load_pdptrs().
Instead it should #GP upon bad PDPTE values, rather than causing a VM
entry failure.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1361,20 +1361,18 @@ static void
The caching isn't actually implemented here, this is just setting the
stage.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2572,6 +2572,18 @@ void hvm_dump_emulation_state(const char
hvmemul_ctxt->insn_buf);
}
+bool
The caching isn't actually implemented here, this is just setting the
stage.
Touching these anyway also
- make their return values gfn_t
- gva -> gla in their names
- name their input arguments gla
At the use sites do the conversion to gfn_t as suitable.
Signed-off-by: Jan Beulich
---
>>> On 19.07.18 at 12:37, wrote:
> On 19/07/18 11:32, Jan Beulich wrote:
>> Shared resources (L1 cache and TLB in particular) present a risk of
>> information leak via side channels. Provide a means to avoid use of
>> hyperthreads in such cases.
>>
>> Signed-off-by: Jan Beulich
>> Reviewed-by:
If panic is called before init_idle_domain on a tboot-launched system,
then Xen recursively faults in write_ptbase as seen below.
(XEN)[] write_ptbase+0/0x10
(XEN)[] tboot_shutdown+0x6b/0x260
(XEN)[] machine_restart+0xac/0x2d0
(XEN)[] write_ptbase+0/0x10
(XEN)[]
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far use of CPU
registers goes (as those can't change without any other instruction
executing in between),
On 19/07/18 11:32, Jan Beulich wrote:
> Shared resources (L1 cache and TLB in particular) present a risk of
> information leak via side channels. Provide a means to avoid use of
> hyperthreads in such cases.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Reviewed-by: Andrew
Drop unnecessary casts and use bool in favor of bool_t.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Roger Pau Monné
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -345,9 +345,9 @@ static inline int cpulist_scnprintf(char
Shared resources (L1 cache and TLB in particular) present a risk of
information leak via side channels. Provide a means to avoid use of
hyperthreads in such cases.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v3: Also change the actual option string to "smt". Don't default the
Reportedly Intel CPUs which can't broadcast #MC to all targeted
cores/threads because some have CR4.MCE clear will shut down. Therefore
we want to keep CR4.MCE enabled when offlining a CPU, and we need to
bring up all CPUs in order to be able to set CR4.MCE in the first place.
The use of
flight 125412 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125412/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 07/19/2018 01:24 PM, Dan Carpenter wrote:
Reviewed-by: Dan Carpenter
Thank you,
if nobody objects I'll push it to drm-misc-next next Monday
regards,
dan carpenter
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
I've been considering to add a respective command line option for
quite a long time, but never got around to. Now that the TLBleed
information is public[1], we're at a point where we not only want,
but need this, and where perhaps it needs to be the default on
affected systems. The first 2 patches
Reviewed-by: Dan Carpenter
regards,
dan carpenter
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 19.07.18 at 10:59, wrote:
> On 19/07/2018 09:34, Jan Beulich wrote:
> On 19.07.18 at 10:26, wrote:
>>> On 19/07/2018 09:21, Jan Beulich wrote:
>>> On 19.07.18 at 09:59, wrote:
> On 19/07/2018 08:10, Jan Beulich wrote:
>>> @@ -694,18 +699,18 @@ int validate_xstate(u64
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 19 July 2018 10:37
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) ; Wei Liu
>
flight 125292 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 125253 REGR. vs.
124248
>>> On 19.07.18 at 10:43, wrote:
> On 07/19/2018 11:30 AM, Jan Beulich wrote:
> On 19.07.18 at 10:18, wrote:
>>> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila +break;
> +case p2m_access_x:
> +
On Tue, Jul 17, 2018 at 02:38:12PM +0100, Paul Durrant wrote:
> This patch adds a new method to the VT-d IOMMU implementation to find the
> MFN currently mapped by the specified BFN along with a wrapper function in
> generic IOMMU code to call the implementation if it exists.
>
> This
On Tue, Jul 17, 2018 at 02:38:11PM +0100, Paul Durrant wrote:
[...]
> int compat_one_iommu_op(compat_iommu_op_buf_t *buf)
> {
> -compat_iommu_op_t cmp;
> +compat_iommu_op_t cmp = {};
> +size_t offset;
> +static const size_t op_size[] = {
> +[XEN_IOMMUOP_query_reserved] =
From: Oleksandr Andrushchenko
Dan Carpenter has reported that there is the following static checker
warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
314 sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
315
316 if
On 07/19/2018 12:20 PM, Dan Carpenter wrote:
On Thu, Jul 19, 2018 at 12:06:38PM +0300, Oleksandr Andrushchenko wrote:
Hi, Dan!
Thank you for the patch and sorry I was clumsy sending v3.
Do you want me to send v3 now with the fixes for both Xen and CMA?
Thank you,
Sorry, I forgot that you
Oleksandr sent this patch already. Please disregard mine.
regards,
dan carpenter
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Thu, Jul 19, 2018 at 12:06:38PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dan!
>
> Thank you for the patch and sorry I was clumsy sending v3.
>
> Do you want me to send v3 now with the fixes for both Xen and CMA?
>
> Thank you,
Sorry, I forgot that you had sent these earlier. After a
Hi Stefano,
On 18/07/18 18:10, Stefano Stabellini wrote:
On Tue, 17 Jul 2018, Julien Grall wrote:
Hi Stefano,
On 17/07/2018 21:05, Stefano Stabellini wrote:
On Mon, 9 Jul 2018, Julien Grall wrote:
Hi,
On 07/07/18 00:11, Stefano Stabellini wrote:
Introduce an is_console option to allow
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
Hi, Dan!
Thank you for the patch and sorry I was clumsy sending v3.
Do you want me to send v3 now with the fixes for both Xen and CMA?
Thank you,
Oleksandr
On 07/19/2018 11:11 AM, Dan Carpenter wrote:
The xen_drm_front_gem_get_sg_table() function is supposed to return
error pointer. The
On Tue, Jul 17, 2018 at 02:38:10PM +0100, Paul Durrant wrote:
> Ranges that should be considered reserved in the IOMMU are not necessarily
> limited to RMRRs. If iommu_inclusive_mapping is set then any frame number
> falling within an E820 reserved region should also be considered as
> reserved in
1 - 100 of 127 matches
Mail list logo
