flight 122237 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122237/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122170
test-armhf-armhf-libvirt-xsm 14 save
Jan Beulich:
> 1: correct ordering of operations during S3 resume
> 2: suppress BTI mitigations around S3 suspend/resume
> 3: check feature flags after resume
>
> Signed-off-by: Jan Beulich
>
> Simon, could you give this a try please?
Backported to 4.8 it works fine with the two fixes I sent ea
> -Original Message-
> From: Roger Pau Monne
> Sent: 13 April 2018 20:53
> To: Lars Kurth
> Cc: xen-devel ; Daniel Smith
> ; Alexey G ; Stefano
> Stabellini ; Julien Grall ; Paul
> Durrant ; Christopher Clark
> ; Rich Persaud
> Subject: Re: Setting up a call to discuss PCI Emulation - Fut
On 04/13/2018 07:55 PM, David Brown wrote:
On Fri, Apr 13, 2018 at 03:11:46PM -0700, Laura Abbott wrote:
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The few VLAs in use have an upper bound based on a size
of 64K. This doesn't produce an excessively l
flight 122264 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122264/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
This run is configured for baseline tests only.
flight 74601 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74601/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 122250 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122250/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2167c7f7a55b9964912d08aae71879357101ace1
baseline version:
ovmf 54ec85dd2902bd5dee391
flight 14 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/14/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122005
test-armhf-armhf-libvirt-xsm 14 saveresto
This run is configured for baseline tests only.
flight 74598 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74598/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The few VLAs in use have an upper bound based on a size
of 64K. This doesn't produce an excessively large stack so just switch
the upper bound.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbo
This run is configured for baseline tests only.
flight 74595 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74595/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
This run is configured for baseline tests only.
flight 74594 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74594/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64
flight 122212 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122212/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122144
test-armhf-armhf-libvirt 14 sav
Simon Gaiser:
> Jan Beulich:
>> Make sure no previously present features are missing after resume (and
>> the re-loading of microcode), to avoid later crashes or (likely silent)
>> hangs / live locks. This doesn't go beyond checking x86_capability[],
>> but this should be good enough for the immedi
On Fri, Apr 13, 2018 at 10:57:46AM -0700, Raj, Ashok wrote:
> > I'm afraid I don't fully agree - not applying an ucode update to the online
> > CPUs because some are offline isn't any better. Plus (while updating)
> > there's always going to be some discrepancy between ucode versions.
> > As long a
Andrew Cooper:
> On 13/04/18 19:25, Simon Gaiser wrote:
>> Jan Beulich:
>>> NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
>>> may become available only once we're reloaded microcode. Make
>>> SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
>>> the cr
Jan Beulich:
> Make sure no previously present features are missing after resume (and
> the re-loading of microcode), to avoid later crashes or (likely silent)
> hangs / live locks. This doesn't go beyond checking x86_capability[],
> but this should be good enough for the immediate need of making s
flight 122258 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 122174
build-amd64
On 13/04/18 19:25, Simon Gaiser wrote:
> Jan Beulich:
>> NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
>> may become available only once we're reloaded microcode. Make
>> SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
>> the critical period of time.
Jan Beulich:
> NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
> may become available only once we're reloaded microcode. Make
> SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
> the critical period of time.
>
> Also set the MSR back to its intended v
On 04/04/18 00:01, Janakarajan Natarajan wrote:
> From: Suravee Suthikulpanit
>
> This patch introduces a new Xen command line option to enable/disable
> SVM sub-options. Currently, it support sub-option "avic", which can
> be used to enable/disable SVM AVIC feature.
>
> Signed-off-by: Suavee Suth
On 04/04/18 00:01, Janakarajan Natarajan wrote:
> @@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned
> int index)
> return &d->avic_physical_id_table[index];
> }
>
> +static void avic_vcpu_load(struct vcpu *v)
> +{
> +unsigned long tmp;
> +struct arch_svm_
Hi Jan
+ Boris
On Fri, Apr 13, 2018 at 09:57:25AM -0600, Jan Beulich wrote:
> >>> On 30.03.18 at 08:59, wrote:
> > This patch is to backport the patch below from linux kernel.
> >
> > commit 30ec26da9967d0d785abc24073129a34c3211777
> > Author: Ashok Raj
> > Date: Wed Feb 28 11:28
On Fri, Apr 13, 2018 at 12:59:15PM +0100, Lars Kurth wrote:
>
>
> On 13/04/2018, 11:01, "Roger Pau Monne" wrote:
>
> On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
> >
> >
> > On 12/04/2018, 17:41, "Roger Pau Monne" wrote:
> >
> > On Thu, Apr 12, 20
On 04/04/18 00:01, Janakarajan Natarajan wrote:
> From: Suravee Suthikulpanit
>
> AVIC introduces two new #vmexit handlers:
>
> VMEXIT_INCOMP_IPI:
> This occurs when an IPI could not be delivered to all targeted guest
> virtual processors because at least one guest virtual processor
> was not allo
On 04/04/18 00:01, Janakarajan Natarajan wrote:
> From: Suravee Suthikulpanit
>
> Introduce AVIC base initialization code. This includes:
> * Setting up per-VM data structures.
> * Setting up per-vCPU data structure.
> * Initializing AVIC-related VMCB bit fields.
>
> This patch also in
On 13/04/2018, 18:24, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [RFC PATCH 1/2] Add Designated Reviewer (R:) to
MAINTAINERS file and add support for it in get_maintainer.pl"):
> I don't know whether it is needed. The same code block of code is in
Linux and
http://xenbits.xen.org/
Lars Kurth writes ("Re: [RFC PATCH 1/2] Add Designated Reviewer (R:) to
MAINTAINERS file and add support for it in get_maintainer.pl"):
> I don't know whether it is needed. The same code block of code is in Linux
> and
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=scripts/get_maintainer.pl
On 13/04/2018, 18:14, "Ian Jackson" wrote:
Lars Kurth writes ("[RFC PATCH 1/2] Add Designated Reviewer (R:) to
MAINTAINERS file and add support for it in get_maintainer.pl"):
> The syntax has been copied from the Linux Maintainers file. I moved the
following Linux
> get_maintaine
Lars Kurth writes ("[RFC PATCH 1/2] Add Designated Reviewer (R:) to MAINTAINERS
file and add support for it in get_maintainer.pl"):
> The syntax has been copied from the Linux Maintainers file. I moved the
> following Linux
> get_maintainer.pl patches to Xen, fixing up some merge issues (and a bu
The syntax has been copied from the Linux Maintainers file. I moved the
following Linux
get_maintainer.pl patches to Xen, fixing up some merge issues (and a bug).
The get_maintainer.pl changes were based on the following git commits
*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linu
This follows up from a conversation after the April x86 community call, in
which I had
the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS
copying
the R section entries from Linux.git:MAINTAINERS (will need changes to
get_maintainers.pl also)
Lars Kurth (2):
Add Desi
This was discussed in an IRC discussion post the April x86 meeting.
Signed-off-by: Lars Kurth
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 29c0c4b3a7..eb2c78ee43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -144,12 +144,14 @@ F:to
On Tue, Apr 03, 2018 at 06:01:16PM -0500, Janakarajan Natarajan wrote:
> OVERVIEW
>
> This patchset is the first of a two-part patch series to introduce
> the AMD Advanced Virtual Interrupt Controller (AVIC) support.
>
> The AVIC hardware virtualizes local APIC registers of each vCPU via
On 04/13/2018 07:38 PM, Tamas K Lengyel wrote:
> On Fri, Apr 13, 2018 at 8:44 AM, Razvan Cojocaru
> wrote:
>> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>>> Debugging continues.
>>
>> Finally, the attached patch seems to get the display unstuck in my
>> scenario, although for one guest I get:
On Fri, Apr 13, 2018 at 8:44 AM, Razvan Cojocaru
wrote:
> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>> Debugging continues.
>
> Finally, the attached patch seems to get the display unstuck in my
> scenario, although for one guest I get:
>
> (XEN) d2v0 Unexpected vmexit: reason 49
> (XEN) doma
On 13.04.2018 17:59, Michal Hocko wrote:
> On Fri 13-04-18 15:33:28, David Hildenbrand wrote:
>> Some devices (esp. paravirtualized) might want to control
>> - when to online/offline a memory block
>> - how to online memory (MOVABLE/NORMAL)
>> - in which granularity to online/offline memory
>>
>> S
Doug Goldstein writes ("Re: [PATCH] docs/gen-html-index: Make
HTML::TreeBuilder::XPath optional again"):
> Reviewed-by: Doug Goldstein
> Tested-by: Doug Goldstein
>
> The test run is here: https://gitlab.com/cardoe/xen/pipelines/20462270
Thanks. Since this bug was blocking the smoke test, I h
On 4/13/18 8:58 AM, Ian Jackson wrote:
> 7782db9260d4 "docs/gen-html-index: Extract titles from HTML documents"
> requires HTML::TreeBuilder::XPath.
>
> This is sadly not as widely available as I had hoped. Work around
> this problem by making the use of this module optional: instead of
> `use'in
On Fri 13-04-18 15:33:28, David Hildenbrand wrote:
> Some devices (esp. paravirtualized) might want to control
> - when to online/offline a memory block
> - how to online memory (MOVABLE/NORMAL)
> - in which granularity to online/offline memory
>
> So let's add a new flag "driver_managed" and disa
>>> On 30.03.18 at 08:59, wrote:
> This patch is to backport the patch below from linux kernel.
>
> commit 30ec26da9967d0d785abc24073129a34c3211777
> Author: Ashok Raj
> Date: Wed Feb 28 11:28:43 2018 +0100
>
> x86/microcode: Do not upload microcode if CPUs are offline
>
flight 122252 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122252/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 122174
build-amd64
Ian Jackson writes:
> This allows the caller to specify a uid and gid to use, even if there
> is no corresponding password entry. This will be useful in certain
> Xen configurations.
>
> We don't support just -runas because: (i) deprivileging without
> calling setgroups would be ineffective (ii
>>> On 30.03.18 at 08:59, wrote:
> @@ -281,24 +287,52 @@ static int microcode_update_cpu(const void *buf, size_t
> size)
> return err;
> }
>
> -static long do_microcode_update(void *_info)
> +static int __wait_for_cpus(atomic_t *cnt, int timeout)
No new double-underscore prefixed functio
flight 122203 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122203/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 10 debian-install fail REGR. vs. 118324
test-armhf-armhf-li
On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
> Debugging continues.
Finally, the attached patch seems to get the display unstuck in my
scenario, although for one guest I get:
(XEN) d2v0 Unexpected vmexit: reason 49
(XEN) domain_crash called from vmx.c:4120
(XEN) Domain 2 (vcpu#0) crashed on cpu
Doug Goldstein writes ("broken build on staging docs"):
> Since change 7782db9260d4c6499458de4e8d9866bc0427e143 the build has been
> broken. See https://gitlab.com/xen-project/xen/pipelines/20403549 for
> logs. Ultimately its because HTML::TreeBuilder::XPath is now a required
> Perl module. Previou
7782db9260d4 "docs/gen-html-index: Extract titles from HTML documents"
requires HTML::TreeBuilder::XPath.
This is sadly not as widely available as I had hoped. Work around
this problem by making the use of this module optional: instead of
`use'ing at the toplevel, we `require' it in the eval. If
flight 122247 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122247/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 122174
build-amd64
On Tue, Apr 10, 2018 at 09:17:01PM +0200, Paul Semel wrote:
> those are helpful macro to use the time manager correctly
>
> Signed-off-by: Paul Semel
> ---
>
> Notes:
> v4:
> - new patch version
>
> common/time.c | 10 ++
> include/xtf/time.h | 12
> 2 files c
On Tue, Apr 10, 2018 at 09:17:00PM +0200, Paul Semel wrote:
> this function uses mspin_sleep to spin sleep for t milliseconds
>
> Signed-off-by: Paul Semel
> ---
>
> Notes:
> v4:
> - new patch version
>
> common/time.c | 6 ++
> include/xtf/time.h | 1 +
> 2 files changed, 7 i
On Tue, Apr 10, 2018 at 09:16:59PM +0200, Paul Semel wrote:
> this function uses nspin_sleep to spin sleep for t seconds
IMO you can squash this into the previous patch.
> Signed-off-by: Paul Semel
> ---
>
> Notes:
> v4:
> - new patch version
>
> common/time.c | 6 ++
> 1 file cha
On Tue, Apr 10, 2018 at 09:16:58PM +0200, Paul Semel wrote:
> this function spin sleeps for t nanoseconds
>
> Signed-off-by: Paul Semel
> ---
>
> Notes:
> v4:
> - new patch version
>
> common/time.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/common/time.c b
On Tue, Apr 10, 2018 at 09:16:57PM +0200, Paul Semel wrote:
> this function acts as the POSIX gettimeofday function
>
> Signed-off-by: Paul Semel
> ---
>
> Notes:
> v4:
> - new patch version
>
> common/time.c | 30 ++
> include/xtf/time.h | 8
On Tue, Apr 10, 2018 at 09:16:56PM +0200, Paul Semel wrote:
> this function returns the "epoch" time
>
> Signed-off-by: Paul Semel
> ---
>
> Notes:
> v4:
> - new patch version
>
> common/time.c | 39 +++
> include/xtf/time.h | 5 +
> 2 file
Some devices (esp. paravirtualized) might want to control
- when to online/offline a memory block
- how to online memory (MOVABLE/NORMAL)
- in which granularity to online/offline memory
So let's add a new flag "driver_managed" and disallow to change the
state by user space. Device onlining/offlini
On Tue, Apr 10, 2018 at 09:16:55PM +0200, Paul Semel wrote:
> this file is introduce to be able to implement an inter domain
> communication protocol over xenstore. For synchronization purpose, we do
> really want to be able to "control" time
>
> common/time.c: since_boot_time gets the time in nan
On 13/04/18 12:49, Jan Beulich wrote:
> 1: correct ordering of operations during S3 resume
> 2: suppress BTI mitigations around S3 suspend/resume
> 3: check feature flags after resume
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-deve
On 13/04/2018, 11:01, "Roger Pau Monne" wrote:
On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
>
>
> On 12/04/2018, 17:41, "Roger Pau Monne" wrote:
>
> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
>
>
> >may work.
On 13/04/2018, 11:31, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [PATCH 5/5] SUPPORT.md: Document the new text
ordering rule"):
...
> +In each case, descriptions which expand on the name of a feature as
> +provided in the section heading, precede the Status indications
Make sure no previously present features are missing after resume (and
the re-loading of microcode), to avoid later crashes or (likely silent)
hangs / live locks. This doesn't go beyond checking x86_capability[],
but this should be good enough for the immediate need of making sure
that the BIT miti
NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
may become available only once we're reloaded microcode. Make
SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
the critical period of time.
Also set the MSR back to its intended value.
Signed-off-by: Jan
Microcode loading needs to happen before re-enabling interrupts, in case
only updated microcode allows the use of e.g. the SPEC_{CTRL,CMD} MSRs.
Otoh it doesn't need to happen at all when we didn't suspend in the
first place. It needs to happen before spin_debug_enable() though, as it
acquires a lo
>>> On 13.04.18 at 13:37, wrote:
> On 13/04/18 09:39, Jan Beulich wrote:
> On 12.04.18 at 18:55, wrote:
>>> @@ -2029,7 +2035,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
> unsigned long value)
>>> if ( v == curr )
>>> write_debugreg(3, value);
>>>
1: correct ordering of operations during S3 resume
2: suppress BTI mitigations around S3 suspend/resume
3: check feature flags after resume
Signed-off-by: Jan Beulich
Simon, could you give this a try please?
Thanks, Jan
___
Xen-devel mailing list
X
On Fri, 2018-04-13 at 11:29 +, George Dunlap wrote:
> I think as far as backports go, my current RFC would be
> fine. Another possibility, though, would be to simply add a
> migrate() callback to remove the vcpu from the runqueue before
> switching v->processor, *without* removing any of the c
>>> On 13.04.18 at 13:17, wrote:
> On 13/04/18 09:31, Jan Beulich wrote:
> On 12.04.18 at 18:55, wrote:
>>> do_get_debugreg() has several bugs:
>>>
>>> * The %cr4.de condition is inverted. %dr4/5 should be accessible only when
>>>%cr4.de is disabled.
>>> * When %cr4.de is disabled, emu
On 13/04/18 09:39, Jan Beulich wrote:
On 12.04.18 at 18:55, wrote:
>> @@ -2029,7 +2035,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
>> unsigned long value)
>> if ( v == curr )
>> write_debugreg(3, value);
>> break;
>> +
>> +case 4:
>> +
> On Apr 13, 2018, at 10:25 AM, Dario Faggioli wrote:
>
> On Fri, 2018-04-13 at 09:03 +, George Dunlap wrote:
>>> On Apr 12, 2018, at 6:25 PM, Dario Faggioli
>>> wrote:
>>>
>> I think the bottom line is, for this test to be valid, then at this
>> point test_bit(VPF_migrating) *must* imply
On 13/04/18 09:31, Jan Beulich wrote:
On 12.04.18 at 18:55, wrote:
>> do_get_debugreg() has several bugs:
>>
>> * The %cr4.de condition is inverted. %dr4/5 should be accessible only when
>>%cr4.de is disabled.
>> * When %cr4.de is disabled, emulation should yield #UD rather than comple
flight 122239 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122239/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 122174
build-amd64
On Fri, 2018-04-13 at 09:03 +, George Dunlap wrote:
> > On Apr 12, 2018, at 6:25 PM, Dario Faggioli
> > wrote:
> >
> > On the "other CPU", we might be around here [**]:
> >
> > static void vcpu_migrate(struct vcpu *v)
> > {
> >...
> >if ( v->is_running ||
> > !test_and_clear_
flight 16 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/16/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 54ec85dd2902bd5dee39106d5291f71088b7d85a
baseline version:
ovmf bf453d581ecff2a731288
On Fri, Apr 13, Dario Faggioli wrote:
> Yes. In fact, Olaf, I still think that doing a run with George's RFC
> applied, would be useful, if only as a data point.
First tests indicate that this series fixes the bug.
Olaf
signature.asc
Description: PGP signature
_
Lars Kurth writes ("Re: [PATCH 5/5] SUPPORT.md: Document the new text ordering
rule"):
...
> +In each case, descriptions which expand on the name of a feature as
> +provided in the section heading, precede the Status indications.
>
> The following is a little clearer
> s/, descriptions wh
On 13/04/18 11:59, Andrew Cooper wrote:
> On 12/04/18 19:09, Juergen Gross wrote:
>> This patch series aims at reducing the overhead of the XPTI Meltdown
>> mitigation.
>
> Sadly, there are still problems.
>
> (XEN) [ 13.486805] Dom0 has maximum 2 VCPUs
> (XEN) [ 13.486824] [ Xen-4.11.0-
Hi Julien,
On Thu, Apr 12, 2018 at 10:43 AM, Julien Grall wrote:
>
>
> On 11/04/18 17:37, Mirela Simonovic wrote:
>>
>> Hi Julien,
>
>
> Hi,
>
> May I ask you to configure your mail client to use > for quoting and use
> plain text? Otherwise, this is going to be really difficult to follow the
> d
On 12/04/2018, 19:26, "Ian Jackson" wrote:
Signed-off-by: Ian Jackson
---
SUPPORT.md | 5 +
1 file changed, 5 insertions(+)
diff --git a/SUPPORT.md b/SUPPORT.md
index 5ae84cf..098262b 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -725,6 +725,11 @@ T
Hi Dario,
On Thu, Apr 12, 2018 at 6:49 PM, Dario Faggioli wrote:
> On Wed, 2018-04-11 at 15:19 +0200, Mirela Simonovic wrote:
>> Secondary pCPUs will be offlined on system suspend and hotplugged
>> on resume. When offlining secondary CPUs all interrupts targeted
>> to those CPUs will be routed to
On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
>
>
> On 12/04/2018, 17:41, "Roger Pau Monne" wrote:
>
> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
>
>
> >may work. For me Mon, Wed and Fri’s generally work at those
> time-slots.
> >Next week
On 12/04/18 19:09, Juergen Gross wrote:
> This patch series aims at reducing the overhead of the XPTI Meltdown
> mitigation.
Sadly, there are still problems.
(XEN) [ 13.486805] Dom0 has maximum 2 VCPUs
(XEN) [ 13.486824] [ Xen-4.11.0-5.0.3-d x86_64 debug=y Not tainted
]
(XEN) [
On 13/04/2018, 09:13, "Jan Beulich" wrote:
>>> On 12.04.18 at 18:32, wrote:
> I had an action to set up a call on discussing the future direction of
PCI
> Emulation. I CC’ed everyone who raised an interest. I propose to use
> Gotomeeting unless there are objections.
On Fri, 2018-04-13 at 09:03 +, George Dunlap wrote:
> > On Apr 12, 2018, at 6:25 PM, Dario Faggioli
> > wrote:
> >
> I think the bottom line is, for this test to be valid, then at this
> point test_bit(VPF_migrating) *must* imply !vcpu_on_runqueue(v), but
> at this point it doesn’t: If someon
flight 74590 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74590/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i38
> On Apr 12, 2018, at 6:25 PM, Dario Faggioli wrote:
>
> On Thu, 2018-04-12 at 17:38 +0200, Dario Faggioli wrote:
>> On Thu, 2018-04-12 at 15:15 +0200, Dario Faggioli wrote:
>>> On Thu, 2018-04-12 at 14:45 +0200, Olaf Hering wrote:
dies after the first iteration.
BU
On Fri, 2018-04-13 at 08:23 +0200, Olaf Hering wrote:
> Am Thu, 12 Apr 2018 19:25:43 +0200
> schrieb Dario Faggioli :
>
> > Olaf, new patch! :-)
>
> BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc)));
>
Thanks!
> (XEN) CPU 36: d10v1 isr=0 runnbl=1 proc=36 pf=0 orq=0 csf=4
>
So, FTR:
- CPU is smp_proce
flight 122230 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122230/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 122174
build-amd64
>>> On 12.04.18 at 20:09, wrote:
> For mitigation of Meltdown the current L4 page table is copied to the
> cpu local root page table each time a 64 bit pv guest is entered.
>
> Copying can be avoided in cases where the guest L4 page table hasn't
> been modified while running the hypervisor, e.g.
>>> On 12.04.18 at 18:55, wrote:
> * Change 'int i' to being unsigned, and move it into its most narrow scope.
> * Fold the access_ok() checks for %dr{0..3}. This halves the compiled size
>of the function.
> * Additional newlines in appropriate places.
>
> Signed-off-by: Andrew Cooper
R
>>> On 12.04.18 at 18:55, wrote:
> @@ -2029,7 +2035,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
> unsigned long value)
> if ( v == curr )
> write_debugreg(3, value);
> break;
> +
> +case 4:
> +if ( v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE )
>>> On 12.04.18 at 18:55, wrote:
> do_get_debugreg() has several bugs:
>
> * The %cr4.de condition is inverted. %dr4/5 should be accessible only when
>%cr4.de is disabled.
> * When %cr4.de is disabled, emulation should yield #UD rather than complete
>with zero.
> * Using -EINVAL for e
>>> On 13.04.18 at 07:25, wrote:
> On Thu, Apr 12, 2018 at 09:29:34AM -0700, Raj, Ashok wrote:
>>On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote:
>>> From: Gao Chao
>>>
>>> This patch is to backport microcode improvement patches from linux
>>> kernel. Below are the original patches desc
flight 122185 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
122170
Tests which
>>> On 12.04.18 at 18:32, wrote:
> I had an action to set up a call on discussing the future direction of PCI
> Emulation. I CC’ed everyone who raised an interest. I propose to use
> Gotomeeting unless there are objections.
FTR - I had expressed an interest too; I can't really plan for the next
On 12/04/2018, 19:29, "Ian Jackson" wrote:
Ian Jackson writes ("[PATCH 0/5] SUPPORT.md: Distinguish descriptions from
caveats"):
> The new support matrix output puts a [*] after each entry in the
> support matrix in many cases where the linked-to text is simply a
> longer desc
>>> On 12.04.18 at 19:56, wrote:
> On 04/12/2018 04:06 AM, Jan Beulich wrote:
>> Jürgen, Boris,
>>
>> looks like commit 47b02f4c62 ("x86/xen: add tty0 and hvc0 as
>> preferred consoles for dom0") doesn't get us quite there yet - non-
>> kernel boot output (and a console prompt) still doesn't appea
96 matches
Mail list logo
