Hi,
On 29/01/2019 14:43, Norbert Manthey wrote:
Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
L1 cache is problemetic, because when hyperthreading is used as well, a
s/problemetic/problematic/
guest running on the sibling core can leak this potentially secret data.
On Thu, Feb 07, 2019 at 06:51:57PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Feb 07, 2019 at 06:40:16PM +0100, Roger Pau Monné wrote:
> > On Thu, Feb 07, 2019 at 04:41:38PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Feb 07, 2019 at 03:57:54PM +0100, Roger Pau Monné wrote:
> > >
On Thu, Feb 07, 2019 at 06:05:24PM +, George Dunlap wrote:
> On 2/7/19 5:57 PM, Roger Pau Monné wrote:
> > On Thu, Feb 07, 2019 at 05:49:16PM +, George Dunlap wrote:
> >> On 1/30/19 10:36 AM, Roger Pau Monne wrote:
> >>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> >
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the vmx_vmexit_handler() code
that checks if the guest has the ability to sw
On Fri, Feb 08, 2019 at 10:35:37AM +0100, Roger Pau Monné wrote:
> What about hot-unplug? The proper flow there would be to ask the
> stubdomain to detach the device, and only deassign it after the
> stubdomain has reported successful detach. I think that's already the
> case.
I think so.
The app
Stubdomains need to be given sufficient privilege over the guest which it
provides emulation for in order for PCI passthrough to work correctly.
When a HVM domain try to enable MSI, QEMU in stubdomain calls
PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq as
part of xc_domain_u
>>> On 08.02.19 at 10:56, wrote:
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).
>
> This can lead to domain crashes in the vmx_vmexit_handler() code
>
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 2019年2月6日 5:39
> To: xen-devel@lists.xenproject.org
> Cc: sstabell...@kernel.org; Stefano Stabellini ;
> julien.gr...@arm.com; Peng Fan ; jgr...@suse.com
> Subject: [PATCH for-4.12] xen/arm: gic-v2: de
On Thu, Feb 7, 2019 at 5:48 PM Roger Pau Monné wrote:
>
> On Thu, Feb 07, 2019 at 05:09:14PM +, George Dunlap wrote:
> > On Wed, Jan 30, 2019 at 10:37 AM Roger Pau Monne
> > wrote:
> > >
> > > There have been several reports of the dom0 builder running out of
> > > memory when buildign a PVH
On 2/8/19 12:51 PM, Jan Beulich wrote:
On 08.02.19 at 10:56, wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the
>>> On 28.01.19 at 08:06, wrote:
> @@ -208,6 +210,58 @@ static void microcode_fini_cpu(unsigned int cpu)
> spin_unlock(µcode_mutex);
> }
>
> +/* Save a ucode patch to the global cache list */
> +bool save_patch(struct microcode_patch *new_patch)
> +{
> +struct microcode_patch *microcod
On 2/8/19 1:13 PM, Razvan Cojocaru wrote:
On 2/8/19 12:51 PM, Jan Beulich wrote:
On 08.02.19 at 10:56, wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea
>>> On 08.02.19 at 12:58, wrote:
> On 2/8/19 1:13 PM, Razvan Cojocaru wrote:
>> On 2/8/19 12:51 PM, Jan Beulich wrote:
>> On 08.02.19 at 10:56, wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
>
On Fri, Feb 08, 2019 at 05:21:44AM +, osstest service owner wrote:
> flight 133030 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/133030/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could
On 2/8/19 2:58 PM, Jan Beulich wrote:
Well, to be honest I expected dependencies like this to be there,
and hence I didn't expect it would be a straightforward change.
Just like we do e.g. for the IOMMU enabling, I guess the boolean
wants to become a tristate then (off -> enabling -> enabled),
wh
On Thu, Feb 7, 2019 at 11:42 AM Jan Beulich wrote:
>
> A previously bad situation has become worse with the early setting of
> ->max_vcpus: The value returned by shadow_min_acceptable_pages() has
> further grown, and hence now holds back even more memory from use for
> the p2m.
>
> Make sh_min_all
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
Guests can issue event channel interaction with guest specified data.
To avoid speculative out-of-bound accesses, we use the nospec macros,
or the domain_vcpu function.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
Notes:
v6: drop vcpu
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, variables are initialized and the compi
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
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
Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
L1 cache is problematic, 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
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
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,
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
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the vmx_vmexit_handler() code
that checks if the guest has the ability to sw
On 2/8/19 4:00 PM, Razvan Cojocaru wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the vmx_vmexit_handler() code
th
Hi,
Please don't send the next version in reply-to a random e-mail from the previous
version. Instead you should create a new thread to make things easier for review.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi there!
Following a Twitter discussion with Netdata people (see
https://twitter.com/linuxnetdata/status/1093834441930215425) we would like
to help them to build a Netdata plugin [1] for gathering Xen metrics. From
the Dom0, no need to access those from the "outside".
Right now, there is RRDs ga
On Fri, Jan 25, 2019 at 07:44:40PM +0100, Sander Eikelenboom wrote:
> On 25/01/2019 15:38, Roger Pau Monné wrote:
> > On Thu, Jan 24, 2019 at 01:04:31PM +0100, Roger Pau Monné wrote:
> > Sorry, fixing that error took longer than expected, and requires
> > modifying quite a lot of code, so I'm not s
>>> On 08.02.19 at 15:00, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4525,7 +4525,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_set_domain_state:
> {
> struct vcpu *v;
> -bool_t ostate;
> +bool ostate, nstate;
>
> if
>>> On 28.01.19 at 08:06, wrote:
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -297,6 +297,10 @@ static int apply_microcode(unsigned int cpu)
>
> uci->cpu_sig.rev = rev;
>
> +#if CONFIG_HVM
> +svm_host_osvw_init();
> +#endif
#ifdef (it's been wrong at
16:06:12.126] Xen is relinquishing VGA console.
(XEN) [2019-02-08 16:06:12.229] *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) [2019-02-08 16:06:12.229] Freed 476kB init memory
(XEN) [2019-02-08 16:06:12.517] Dom0 callback via changed to Direct Vector 0xf3
[0
>>> On 28.01.19 at 08:06, wrote:
> @@ -30,18 +31,25 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
>
> +#include
> #include
> #include
> #include
> #include
>
> +/* By default, wait for 3us */
> +#define MICROCODE_DEFAULT
On 2/8/19 5:50 PM, Jan Beulich wrote:
On 08.02.19 at 15:00, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4525,7 +4525,7 @@ static int do_altp2m_op(
>> case HVMOP_altp2m_set_domain_state:
>> {
>> struct vcpu *v;
>> -bool_t ostate;
>>
>>> On 08.02.19 at 17:30, wrote:
> On 2/8/19 5:50 PM, Jan Beulich wrote:
> On 08.02.19 at 15:00, wrote:
>>> /* If the alternate p2m state has changed, handle appropriately */
>>> -if ( d->arch.altp2m_active != ostate &&
>>> +if ( nstate != ostate &&
>>>
On Fri, Feb 08, 2019 at 05:15:22PM +0100, Sander Eikelenboom wrote:
> On 08/02/2019 16:10, Roger Pau Monné wrote:
> > On Fri, Jan 25, 2019 at 07:44:40PM +0100, Sander Eikelenboom wrote:
> >> On 25/01/2019 15:38, Roger Pau Monné wrote:
> >>> On Thu, Jan 24, 2019 at 01:04:31PM +0100, Roger Pau Monné
On 2/8/19 6:44 PM, Jan Beulich wrote:
On 08.02.19 at 17:30, wrote:
>> On 2/8/19 5:50 PM, Jan Beulich wrote:
>> On 08.02.19 at 15:00, wrote:
/* If the alternate p2m state has changed, handle appropriately */
-if ( d->arch.altp2m_active != ostate &&
+
flight 133035 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133035/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On Thu, Feb 07, 2019 at 05:21:28PM +, George Dunlap wrote:
> On 2/5/19 1:38 PM, Roger Pau Monné wrote:
> > On Tue, Feb 05, 2019 at 05:44:14AM -0700, Jan Beulich wrote:
> > On 05.02.19 at 11:40, wrote:
> >>> On Tue, Feb 05, 2019 at 12:45:56AM -0700, Jan Beulich wrote:
> >>> On 04.02.19
On Thu, Feb 07, 2019 at 04:44:17PM +, Wei Liu wrote:
> Page tables allocated in that function should be mapped and unmapped
> now.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/mm.c | 31 ++-
> 1 file changed, 22 insertions(+), 9 deletions(-)
>
Gitlab CI has d
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree:
CC Stefano as well
On Fri, Feb 08, 2019 at 01:14:16PM +, Wei Liu wrote:
> On Fri, Feb 08, 2019 at 05:21:44AM +, osstest service owner wrote:
> > flight 133030 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/133030/
> >
> > Failures and problems with tes
Hi,
> Would try changes mentioned by you.
We managed to boot XEN with dom0 kernel on H3.
But we see following , when we try to domU guest:
# xl create -c config.xl
Parsing config from config.xl
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/block add [2417] exite
flight 132995 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132995/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
Hi,
Upstream mailing list is at:
xen-devel@lists.xenproject.org
Apparently,
x...@packages.debian.org
results in a message to
pkg-xen-de...@lists.alioth.debian.org
On 2/8/19 6:13 PM, Samuel Thibault wrote:
>
> Sacha, le ven. 08 févr. 2019 18:00:22 +0100, a ecrit:
>> On Debian GNU/Linux 9.
On 08/02/2019 17:47, Roger Pau Monné wrote:
> On Fri, Feb 08, 2019 at 05:15:22PM +0100, Sander Eikelenboom wrote:
>> On 08/02/2019 16:10, Roger Pau Monné wrote:
>>> On Fri, Jan 25, 2019 at 07:44:40PM +0100, Sander Eikelenboom wrote:
On 25/01/2019 15:38, Roger Pau Monné wrote:
> On Thu, Jan
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/xen-n
From: "Gustavo A. R. Silva"
Date: Fri, 8 Feb 2019 13:58:38 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -W
On 2/8/19 2:21 PM, David Miller wrote:
> From: "Gustavo A. R. Silva"
> Date: Fri, 8 Feb 2019 13:58:38 -0600
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This pa
flight 133050 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133050/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
From: Sacha
To: xen-de...@lists.xen.org
Subject: [admin] [BUG] task jbd2/xvda4-8:174 blocked for more than 120 seconds.
Hi,
On Debian GNU/Linux 9.7 (stretch) amd64, we have a bug on the last Xen
Hypervisor version:
xen-hypervisor-4.8-amd64 4.8.5+shim4.10.2+xsa282
The rollback on the previ
From: Samuel Thibault
To: xen-de...@lists.xen.org, x...@packages.debian.org
Subject: Re: [admin] [BUG] task jbd2/xvda4-8:174 blocked for more than 120
seconds.
Hello,
Sacha, le ven. 08 févr. 2019 18:00:22 +0100, a ecrit:
> On Debian GNU/Linux 9.7 (stretch) amd64, we have a bug on the last Xen
flight 133025 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133025/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7a90895306acbf970de87e8020f8c6dc22ce8fb3
baseline version:
ovmf bac50dfbcd92f45165feb
flight 133015 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133015/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
flight 133013 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133013/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
flight 133019 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133019/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradi
flight 133033 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133033/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
Hello,
Hans van Kranenburg, le ven. 08 févr. 2019 20:18:44 +0100, a ecrit:
> Upstream mailing list is at:
> xen-devel@lists.xenproject.org
Apparently it didn't get the mails, I guess because it's subscriber-only
posting? I have now forwarded the mails.
> Apparently,
> x...@packages.debian.or
Hello,
Sacha, le ven. 08 févr. 2019 18:00:22 +0100, a ecrit:
> On Debian GNU/Linux 9.7 (stretch) amd64, we have a bug on the last Xen
> Hypervisor version:
>
> xen-hypervisor-4.8-amd64 4.8.5+shim4.10.2+xsa282
(Read: 4.8.5+shim4.10.2+xsa282-1+deb9u11)
> The rollback on the previous package
Hi,
On Debian GNU/Linux 9.7 (stretch) amd64, we have a bug on the last Xen
Hypervisor version:
xen-hypervisor-4.8-amd64 4.8.5+shim4.10.2+xsa282
The rollback on the previous package version corrected the problem:
xen-hypervisor-4.8-amd64 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
The err
63 matches
Mail list logo
