This run is configured for baseline tests only.
flight 74963 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74963/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 79b10d4ce4f08aab4b9548fabc4542ca78a96247
baseline
flight 125077 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125077/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 broken in 125005
On Thu, Jul 12, 2018 at 02:33:42PM -0500, Doug Goldstein wrote:
> On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote:
> > We don't need to specify /bin/bash in the entry point rune, otherwise
> > non-interactive invocation of the container would fail with something
> > like:
> >
> > +
flight 125143 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125143/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 79b10d4ce4f08aab4b9548fabc4542ca78a96247
baseline version:
ovmf
Hi Lars,
I think I have sent the minutes of design session to you. I attached the email
in case you can’t found.
Thanks,
Luwei Kang
From: Lars Kurth [mailto:lars.ku...@citrix.com]
Sent: Thursday, July 12, 2018 9:23 PM
To: Ji, John ; xen-devel
Cc: committ...@xenproject.org; Tamas K Lengyel ;
On Tue, 10 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/07/2018 01:00, Stefano Stabellini wrote:
> > On Mon, 9 Jul 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 07/07/18 00:12, Stefano Stabellini wrote:
> > > > Remove the cmdline field from struct boot_module, cmdline is stored
> >
flight 125142 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125142/
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
This run is configured for baseline tests only.
flight 74962 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74962/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0a563f3fecfd9baffe8dce51bb4411d6a748a936
baseline
flight 125140 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125135
Tests which
On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote:
> We don't need to specify /bin/bash in the entry point rune, otherwise
> non-interactive invocation of the container would fail with something
> like:
>
> + C=debian:stretch-i386
> + export
flight 74961 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74961/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 74938
jobs:
build-amd64 pass
Hi,
Would it be possible to provide a branch with the patch applied? It
would be nice to have that for every version, so I can easily know on
which version of you are based and avoid spending time trying to apply
it :).
Cheers,
--
Julien Grall
Hi Stefano,
On 07/07/2018 00:12, Stefano Stabellini wrote:
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed
flight 125135 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125135/
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/12/2018 11:40 AM, Juergen Gross wrote:
> Setting pv_irq_ops for Xen PV domains should be done as early as
> possible in order to support e.g. very early printk() usage.
>
> The same applies to xen_vcpu_info_reset(0), as it is needed for the
> pv irq ops.
>
> Move the call of
Otherwise we may leak kernel stack for events that sample user
registers.
Reported-by: Mark Rutland
Signed-off-by: Boris Ostrovsky
Cc: sta...@vger.kernel.org
---
arch/x86/xen/pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index
In the x86 test harness and the fuzzer, and instead create a link in
the tools/include directory that can be used by all the tools.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
---
Changes since v1:
- Don't remove
flight 125072 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 broken
build-i386-libvirt6
>>> On 12.07.18 at 17:39, wrote:
> Ian Jackson writes ("[PATCH v3] xen: oprofile/nmi_int.c: Drop unwanted sexual
> reference"):
>> This is not really very nice.
>>
>> This line doesn't have much value in itself. The rest of this comment
>> block is pretty clear what it wants to convey. So
On Thu, Jul 12, 2018 at 01:35:14PM +0200, Daniel Kiper wrote:
> On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
> > This allows removing the DEFINED conditional in the linker script, and
> > fixes compilation with lld:
>
> s/lld/LLVM linker/?
>
> Could you mention the version of
>>> On 12.07.18 at 17:20, wrote:
> On Thu, Jul 12, 2018 at 06:01:43AM -0600, Jan Beulich wrote:
>> >>> On 12.07.18 at 12:40, wrote:
>> > --- a/tools/include/Makefile
>> > +++ b/tools/include/Makefile
>> > @@ -21,6 +21,9 @@ xen/.dir:
>> >ln -sf $(addprefix
Sorry for not noticing that you had replied.
Anthony PERARD writes ("Re: [PATCH v3.1] libxl: Design of an async API to issue
QMP commands to QEMU"):
> Before replying to this email, here is the description of what state a
> QMP connection can be. This states are only internal to libxl_qmp.c, the
We don't need to specify /bin/bash in the entry point rune, otherwise
non-interactive invocation of the container would fail with something
like:
+ C=debian:stretch-i386
+ export CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
+
On Thu, Jul 12, 2018 at 08:53:06AM -0500, Doug Goldstein wrote:
> This adds a script that can be used to do builds easily within the
> defined containers under the automation directory. These containers live
> in the public GitLab registry under the xen-project namespace. The
> script can be
On 11/07/18 13:10, Jan Beulich wrote:
> Shared resources (L1 cache and TLB in particular) present a risk of
> information leak via side channels. Don't use hyperthreads in such
> cases, but allow independent control of their use at the same time.
>
> Signed-off-by: Jan Beulich
> ---
> An option
On 11/07/18 13:09, Jan Beulich wrote:
> 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
On Thu, Jul 12, 2018 at 01:38:21PM +0200, Daniel Kiper wrote:
> On Wed, Jul 11, 2018 at 05:34:48PM +0200, Roger Pau Monne wrote:
> > With '|'. The result is the same, and the later works with lld. Fixes
> > the following error when building Xen with lld:
> >
> > ld-melf_x86_64_fbsd -T xen.lds
Setting pv_irq_ops for Xen PV domains should be done as early as
possible in order to support e.g. very early printk() usage.
The same applies to xen_vcpu_info_reset(0), as it is needed for the
pv irq ops.
Move the call of xen_setup_machphys_mapping() after initializing the
pv functions as it
Ian Jackson writes ("[PATCH v3] xen: oprofile/nmi_int.c: Drop unwanted sexual
reference"):
> This is not really very nice.
>
> This line doesn't have much value in itself. The rest of this comment
> block is pretty clear what it wants to convey. So delete it.
>
> (While we are here, adopt the
This is not really very nice.
This line doesn't have much value in itself. The rest of this comment
block is pretty clear what it wants to convey. So delete it.
(While we are here, adopt the CODING_STYLE-mandated formatting.)
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
Acked-by: Lars Kurth
On Thu, Jul 12, 2018 at 06:01:43AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 12:40, wrote:
> > --- a/tools/include/Makefile
> > +++ b/tools/include/Makefile
> > @@ -21,6 +21,9 @@ xen/.dir:
> > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h)
> > xen/libelf/
> >
>>> On 12.07.18 at 17:08, wrote:
> This is not really very nice.
>
> This line doesn't have much value in itself. The rest of this comment
> block is pretty clear what it wants to convey. So delete it.
>
> (While we are here, adopt the CODING_STYLE-mandated formatting.)
>
> Signed-off-by:
On Wed, Jul 11, 2018 at 06:12:14AM -0600, Jan Beulich wrote:
> Drop unnecessary casts and use bool in favor of bool_t.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Thank you Rich to share this with the XEN community,
Any comment is welcome.
Regards,
On Thu, Jul 12, 2018 at 2:39 PM, Rich Persaud wrote:
> Thanks to everyone who contributed to the AGL virtualization white paper
> and to Michele Paolino for stewarding it from concept to final publication.
>
This is not really very nice.
This line doesn't have much value in itself. The rest of this comment
block is pretty clear what it wants to convey. So delete it.
(While we are here, adopt the CODING_STYLE-mandated formatting.)
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
Acked-by: Lars Kurth
On Thu, Jul 12, 2018 at 03:50:07PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 6/6] osstest: add FreeBSD Xen build job"):
> > To both the FreeBSD and the xen-unstable flights.
> >
> > This is the runvar difference of a xen-unstable flight:
>
> Can you split out the
> On 12 Jul 2018, at 15:49, Wei Liu wrote:
>
> On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
>> This is not really very nice.
>>
>> I don't understand the technical details here but `violence' is
>> probably fair. The word `violence' is often used metaphorically in a
>>
On Thu, Jul 12, 2018 at 3:52 PM, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop
> unwanted sexual reference"):
>> On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
>> > - /* We walk a thin line between law and rape here.
>> > + /* We
Wei Liu writes ("Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop unwanted
sexual reference"):
> On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
> > - /* We walk a thin line between law and rape here.
> > + /* We walk a thin line between law and violence here.
>
> IMHO this
On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
> This is not really very nice.
>
> I don't understand the technical details here but `violence' is
> probably fair. The word `violence' is often used metaphorically in a
> technical context so I think it's probably OK for use in this
Roger Pau Monne writes ("[PATCH v2 6/6] osstest: add FreeBSD Xen build job"):
> To both the FreeBSD and the xen-unstable flights.
>
> This is the runvar difference of a xen-unstable flight:
Can you split out the refactoring, please ?
That way I can do my own runvar difference on the
The default make on FreeBSD is the BSD make, and Xen requires the GNU
make in order to build. Set the make command based on the OS for the
Xen build.
Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
---
Changes since v1:
- Use gmake for all BSDs.
---
ts-xen-build | 11 ++-
1 file
From: Ian Jackson
So that the contents of the runvar can be expanded. There are
currently two ways to do this:
- Using += will append to the end of the runvar.
- Using ,= will append to the end of the runvar using ',' as the
separator.
Note that if the runvar is empty {,|+}= just sets the
The set_freebsd_runvars helper in mfi-common is a superset of the
original function present in make-freebsd-flight, and will attempt to
fetch the last anointed FreeBSD build as a last resort option if no
FreeBSD build is signaled from the FreeBSD env vars. There's no reason
to have this
There's no support yet in osstest to install FreeBSD from UEFI, so for
the time being limit the FreeBSD jobs to boxes booting with legacy
BIOS.
The hostflags are not set for examine jobs, in order to avoid them
from only running on BIOS boxes.
Signed-off-by: Roger Pau Monné
Acked-by: Ian
To both the FreeBSD and the xen-unstable flights.
This is the runvar difference of a xen-unstable flight:
+build-amd64-xen-freebsd all_host_os freebsd
+build-amd64-xen-xsm-freebsd all_host_os freebsd
+build-amd64-xen-freebsd all_hostflagsPropEq:Firmware:bios:bios
Hello,
The first 4 patches in this patch series prevent FreeBSD jobs from
running on boxes booting from UEFI. This is needed due to osstest lack
of support for installing FreeBSD from UEFI at the moment.
Last two patches add support for creating Xen build jobs running on
FreeBSD. Such a job is
Into a helper. A diff of the runvars of flights generated with and
without the patch show no differences.
No functional change.
Signed-off-by: Roger Pau Monné
---
make-freebsd-flight | 24 +---
mfi-common | 14 ++
2 files changed, 19 insertions(+), 19
flight 125070 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl 4
This is not really very nice.
I don't understand the technical details here but `violence' is
probably fair. The word `violence' is often used metaphorically in a
technical context so I think it's probably OK for use in this way.
IMO this patch should be backported to all maintained trees.
>>> On 12.07.18 at 15:02, wrote:
> On 11/07/18 13:07, Jan Beulich wrote:
>> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
>> the difference is not very big. The most relevant change (requiring some
>> code restructuring) is that the topoext feature no longer means there
All,
I am pleased to announce the release of Xen 4.8.4. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8
(tag RELEASE-4.8.4) or from the XenProject download page
On Wed, Jul 11, 2018 at 02:16:16PM +0100, Wei Liu wrote:
> Install nasm and build ovmf with gcc on x86.
>
> Signed-off-by: Wei Liu
> ---
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
This adds a script that can be used to do builds easily within the
defined containers under the automation directory. These containers live
in the public GitLab registry under the xen-project namespace. The
script can be executed a number of ways but the default is to drop you
at a bash shell
John,
Thank you. I have notes and slides for SGX, which are already published and
Intel Processor Trace (just the slides – already published, but I am not sure
whether these already were updated to reflect the design discussion) and
EPT-Based Sub-Page Protection (just the slides – already
This run is configured for baseline tests only.
flight 74959 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74959/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 895b87e38015e0698c6a5c0633e0156b038a56f1
baseline
flight 125069 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125069/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 123554
On 11/07/18 13:07, Jan Beulich wrote:
> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
> the difference is not very big. The most relevant change (requiring some
> code restructuring) is that the topoext feature no longer means there is
> a valid CU ID.
>
> Take the
On 11/07/18 13:06, Jan Beulich wrote:
> The function's use of the stop-machine logic has so far prevented its
> use ahead of the processing of the "ordinary" initcalls. Since at this
> early time we're in a controlled environment anyway, there's no need for
> such a heavy tool. Additionally this
On 11/07/18 13:06, Jan Beulich wrote:
> In order to be able to service #MC on offlined CPUs, GDT, IDT, stack,
For clarity, I'd phrase this as "CPUs, the GDT, ..." to help visually
separate CPUs as it isn't a part of the rest of the list.
> --- a/xen/arch/x86/genapic/x2apic.c
> +++
Thanks to everyone who contributed to the AGL virtualization white paper and to
Michele Paolino for stewarding it from concept to final publication. I’ve
added it to the Xen wiki:
https://wiki.xenproject.org/wiki/Automotive_Whitepapers
Rich___
I will Yu and Yi to send out discussion notes.
>>### Add vNVDIMM support to HVM domains
>>Stakeholders: Zhang Yi, Intel, Zhang Yu, Intel, George Dunlap, Citrix ``` _As
>>far as I understand a simple and clean way to implement this has been found,
>>but the design session notes are still
On Thu, Jul 12, 2018 at 02:58:00PM +0300, Oleksandr Andrushchenko wrote:
> On 06/18/2018 03:32 PM, Oleksandr Andrushchenko wrote:
> > On 06/18/2018 03:29 PM, Dan Carpenter wrote:
> > > On Mon, Jun 18, 2018 at 09:07:09AM +0300, Oleksandr Andrushchenko wrote:
> > > >
flight 125124 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125124/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0a563f3fecfd9baffe8dce51bb4411d6a748a936
baseline version:
ovmf
>>> On 12.07.18 at 12:40, wrote:
> --- a/tools/include/Makefile
> +++ b/tools/include/Makefile
> @@ -21,6 +21,9 @@ xen/.dir:
> ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h)
> xen/libelf/
> ln -s ../xen-foreign xen/foreign
> ln -sf
On 06/18/2018 03:32 PM, Oleksandr Andrushchenko wrote:
On 06/18/2018 03:29 PM, Dan Carpenter wrote:
On Mon, Jun 18, 2018 at 09:07:09AM +0300, Oleksandr Andrushchenko wrote:
drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
2 files changed, 2
>>> On 12.07.18 at 13:37, wrote:
> On 11/07/18 16:34, Roger Pau Monne wrote:
>> And replace the open-coded versions already in tree. No functional
>> change.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Jan Beulich
>> Cc: Andrew Cooper
>> Cc: Daniel Kiper
>> ---
>>
>>> On 12.07.18 at 13:35, wrote:
> On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
>> This allows removing the DEFINED conditional in the linker script, and
>> fixes compilation with lld:
>
> s/lld/LLVM linker/?
>
> Could you mention the version of LLVM linker in the commit
>>> On 12.07.18 at 12:52, wrote:
> On Wed, Jul 11, 2018 at 06:26:23AM -0600, Jan Beulich wrote:
>> >>> On 11.07.18 at 13:41, wrote:
>> > On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote:
>> >> >>> On 10.07.18 at 12:48, wrote:
>> >> > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan
>>> On 12.07.18 at 12:53, wrote:
> On Wed, Jul 11, 2018 at 06:06:04AM -0600, Jan Beulich wrote:
> [...]
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
>> cpumask_t cpu_online_map __read_mostly;
>>
On Wed, Jul 11, 2018 at 05:34:48PM +0200, Roger Pau Monne wrote:
> With '|'. The result is the same, and the later works with lld. Fixes
> the following error when building Xen with lld:
>
> ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
>
On 11/07/18 16:34, Roger Pau Monne wrote:
> And replace the open-coded versions already in tree. No functional
> change.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Daniel Kiper
> ---
> xen/include/xen/compiler.h | 2 ++
>
On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
> This allows removing the DEFINED conditional in the linker script, and
> fixes compilation with lld:
s/lld/LLVM linker/?
Could you mention the version of LLVM linker in the commit message?
And I am still not sure why do you
flight 125125 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125125/
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 Thu, Jul 12, 2018 at 02:53:55AM +, osstest service owner wrote:
> flight 125119 ovmf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/125119/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-pvops
This run is configured for baseline tests only.
flight 74958 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74958/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 15
On Thu, Jul 12, 2018 at 12:40:34PM +0200, Roger Pau Monne wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
On Wed, Jul 11, 2018 at 06:33:15AM -0600, Jan Beulich wrote:
> >>> On 11.07.18 at 13:57, wrote:
> > On Tue, Jul 10, 2018 at 08:05:56AM -0600, Jan Beulich wrote:
> >> >>> On 10.07.18 at 13:35, wrote:
> >> > On Fri, Jul 06, 2018 at 09:16:38AM -0600, Jan Beulich wrote:
> >> >> >>> On 06.07.18 at
On Wed, Jul 11, 2018 at 06:06:52AM -0600, Jan Beulich wrote:
> The function's use of the stop-machine logic has so far prevented its
> use ahead of the processing of the "ordinary" initcalls. Since at this
> early time we're in a controlled environment anyway, there's no need for
> such a heavy
On Wed, Jul 11, 2018 at 06:06:04AM -0600, Jan Beulich wrote:
[...]
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
> cpumask_t cpu_online_map __read_mostly;
> EXPORT_SYMBOL(cpu_online_map);
>
> +bool __read_mostly
On Wed, Jul 11, 2018 at 06:26:23AM -0600, Jan Beulich wrote:
> >>> On 11.07.18 at 13:41, wrote:
> > On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote:
> >> >>> On 10.07.18 at 12:48, wrote:
> >> > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan Beulich wrote:
> >> >> >>> On 06.07.18 at
Jan Beulich writes ("RE: [Xen-devel] 4.9.3 preparations"):
> On 11.07.18 at 18:23, wrote:
> > 08641a9e8870d3b174d95aaa55ecba43387563b5 would be nice to have included.
>
> Ian, that's one for you, unless you tell me to take it.
Indeed. I've committed it.
Thanks,
Ian.
On 12/07/18 11:40, Roger Pau Monne wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
In the x86 test harness and the fuzzer, and instead create a link in
the tools/include directory that can be used by all the tools.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
---
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 may have missed some things or misinterpreted them, but it
The notes and PPT were sent to me by Kai to be published
An SGX back-ground presentation can be found at
https://www.slideshare.net/xen_com_mgr/xpdds18-design-session-sgx-deep-dive-and-sgx-virtualization-discussion-kai-huang-intel
Key agreements during a discussion between present maintainers
>>> On 12.07.18 at 09:21, wrote:
>> >>> On 30.05.18 at 15:27, wrote:
>> > @@ -759,12 +760,19 @@ int xc_cpuid_apply_policy(xc_interface *xch,
>> > uint32_t domid,
>> > continue;
>> > }
>> >
>> > +if ( input[0] == 0x14 )
>> > +{
>> > +
Forgot to Cc maintainers.
On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote:
> And replace the open-coded versions already in tree. No functional
> change.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Daniel Kiper
> ---
>
> >>> On 30.05.18 at 15:27, wrote:
> > @@ -759,12 +760,19 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
> > domid,
> > continue;
> > }
> >
> > +if ( input[0] == 0x14 )
> > +{
> > +input[1]++;
> > +if ( input[1] == 1 )
>
flight 125122 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125122/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c563077a380437c114aba4c95be65eb963ebc1f3
baseline version:
ovmf
>>> On 11.07.18 at 18:23, wrote:
> 08641a9e8870d3b174d95aaa55ecba43387563b5 would be nice to have included.
Ian, that's one for you, unless you tell me to take it.
Stewart - it would have been helpful if you also included the title
(and instead perhaps just an abbreviated hash). This way I
91 matches
Mail list logo
