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
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
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,
>
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
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
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
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 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 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
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
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
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
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
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
>
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
---
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,
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
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,
> 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]
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
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:
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
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
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
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 &&
+
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 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 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 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
shing 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.00] Linux version 5.0.0-rc5-2019020
>>> 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
>>> 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;
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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),
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
>>> 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 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
>>> On 28.01.19 at 08:06, wrote:
> @@ -208,6 +210,58 @@ static void microcode_fini_cpu(unsigned int cpu)
> spin_unlock(_mutex);
> }
>
> +/* Save a ucode patch to the global cache list */
> +bool save_patch(struct microcode_patch *new_patch)
> +{
> +struct microcode_patch
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 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
> -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:
>>> 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
>
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
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
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
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
>
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:
> >
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
63 matches
Mail list logo
