On 06/07/18 08:27, Chenjia (C) wrote:
> Dear Juergen:
>We will follow your suggestion: unload DPDK, then test a again.
>
> Our server have 24 vcpu, and if we press '0' it only show 10 vcpu's
> dump message, is there a way to show more dump message?
Hmm, I guess using the 'A' k
>>> On 05.07.18 at 19:19, wrote:
> On 05/07/18 14:54, Jan Beulich wrote:
>> --- a/xen/arch/x86/i387.c
>> +++ b/xen/arch/x86/i387.c
>> @@ -337,6 +337,49 @@ int vcpu_init_fpu(struct vcpu *v)
>> return rc;
>> }
>>
>> +void vcpu_load_fpu(struct vcpu *v, struct xsave_struct *xsave_area,
>
> Ho
Dear Juergen:
We will follow your suggestion: unload DPDK, then test a again.
Our server have 24 vcpu, and if we press '0' it only show 10 vcpu's
dump message, is there a way to show more dump message?
Best Regards
-邮件原件-
发件人: Juergen Gross [mailto:jgr...@suse.com]
On 06/07/18 05:28, Chenjia (C) wrote:
> Dear Juergen:
> Now we are test project on 2 servers, Both 2 servers have the same
> configuration, but one server is install xen4.8.2 with dom0 linux kernel
> version 4.4.103-92.56-default, the other server is xen 4.8.3 with dom0 linux
> kernel 4.4.
Hi,
I'm trying to route all the physical interrupts to the guest domain rather
than being trapped in the Xen. I would like to know what is the right way
to do that?
I know that HCR_IMO bit in the HCR_EL2 register is supposed to be for
routing the interrupts to the guest (Routing to EL1 instead of
flight 124951 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124951/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124389
test-armhf-armhf-lib
On Thu, Jul 5, 2018 at 12:52 PM George Dunlap wrote:
>
> >
> >> Again, there was a sense that some of the issues we are seeing could be
> >> solved if we had better
> >> CI capability: in other words, some of the issues we were seeing could be
> >> resolved by
> >> * Better CI capability as sugg
On Wed, Jun 13, 2018 at 03:15:10PM -0700, Stefano Stabellini wrote:
> Xen boot modules need to account not just for Dom0 but also for a few
> potential DomUs, each of them coming with their own kernel and initrd.
> Increase MAX_MODULES to 32 to allow for more DomUs.
>
> Signed-off-by: Stefano Stab
On Thu, Jul 05, 2018 at 02:02:33PM -0500, Doug Goldstein wrote:
> On Thu, Jul 05, 2018 at 06:51:16PM +, George Dunlap wrote:
> > >
> > >> Again, there was a sense that some of the issues we are seeing could be
> > >> solved if we had better
> > >> CI capability: in other words, some of the i
flight 124950 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken in 124870
build-arm64-libvirt
On Wed, Jul 04, 2018 at 07:57:30AM -0600, Jan Beulich wrote:
> >>> On 04.07.18 at 14:03, wrote:
> > On 04/07/18 09:21, Jan Beulich wrote:
> > On 03.07.18 at 22:55, wrote:
> >>> --- a/tools/include/Makefile
> >>> +++ b/tools/include/Makefile
> >>> @@ -21,6 +21,9 @@ xen/.dir:
> >>> ln -sf $(a
On Thu, 14 Jun 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 13/06/18 23:15, Stefano Stabellini wrote:
> > Introduce functions to generate a basic domU device tree, similar to the
> > existing functions in tools/libxl/libxl_arm.c.
> >
> > Rename existing prepare_dtb to prepare_dtb_dom0 to avoid
On Thu, 14 Jun 2018, Julien Grall wrote:
> Hi,
>
> On 13/06/18 23:15, Stefano Stabellini wrote:
> > Similar to construct_dom0, construct_domU creates a barebone DomU guest.
> > Default to 1 max vcpu and 64MB of memory if not specified otherwise.
> >
> > The device tree node passed as argument is
On 05/07/18 19:11, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> Just wondering, are there any timing statistics kept for the OSStest
>> fligh
On Thu, Jul 05, 2018 at 10:53:22AM -0600, Tamas K Lengyel wrote:
> On Thu, Jul 5, 2018 at 4:44 AM Adrian Pop wrote:
> > @@ -72,11 +83,7 @@ static int _p2m_get_mem_access(struct p2m_domain *p2m,
> > gfn_t gfn,
> > if ( mfn_eq(mfn, INVALID_MFN) )
> > return -ESRCH;
> >
> > -if ( (
Hi Stefano,
On 05/07/2018 21:55, Stefano Stabellini wrote:
On Fri, 15 Jun 2018, Julien Grall wrote:
Hi Stefano,
On 06/15/2018 12:35 AM, Stefano Stabellini wrote:
On Thu, 14 Jun 2018, Julien Grall wrote:
On 13/06/18 23:15, Stefano Stabellini wrote:
if ( !is_hardware_domain(d) )
prepare_dt
flight 124945 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123837
Tests which did not
On Fri, 15 Jun 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 06/15/2018 12:35 AM, Stefano Stabellini wrote:
> > On Thu, 14 Jun 2018, Julien Grall wrote:
> > > On 13/06/18 23:15, Stefano Stabellini wrote:
> > > > -
> > > > -printk("*** LOADING DOMAIN 0 ***\n");
> > > > -if ( dom0_mem <= 0
On Thu, 14 Jun 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 13/06/18 23:15, Stefano Stabellini wrote:
> > Find addresses and sizes on device tree.
> > Introduce a new boot_module_find_by_addr_and_kind function to match not
> > just on boot module kind, but also by address so that we can support
flight 124946 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124946/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 16
depriv-audit-qemu/c
On Thu, Jul 05, 2018 at 06:51:16PM +, George Dunlap wrote:
> >
> >> Again, there was a sense that some of the issues we are seeing could be
> >> solved if we had better
> >> CI capability: in other words, some of the issues we were seeing could be
> >> resolved by
> >> * Better CI capabilit
On Thu, 5 Jul 2018, George Dunlap wrote:
> >> Again, there was a sense that some of the issues we are seeing could be
> >> solved if we had better
> >> CI capability: in other words, some of the issues we were seeing could be
> >> resolved by
> >> * Better CI capability as suggested in the Relea
>
>> Again, there was a sense that some of the issues we are seeing could be
>> solved if we had better
>> CI capability: in other words, some of the issues we were seeing could be
>> resolved by
>> * Better CI capability as suggested in the Release Cadence discussion
>> * Improving some of the
This is a note to let you know that I've just added the patch titled
x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the pat
On Thu, Jul 05, 2018 at 11:39:51AM +, George Dunlap wrote:
>
>
> > On Jul 5, 2018, at 12:16 PM, Ian Jackson wrote:
> >
> > Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> > session] Process changes: is the 6 monthly release Cadence too short,
> > Security Proces
On Thu, Jul 05, 2018 at 12:16:09PM +0100, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
> > We didn't look at the sporadic failing tests thoroughly en
On Tue, Jul 03, 2018 at 12:47:14PM +0200, Juergen Gross wrote:
> On 03/07/18 12:23, Lars Kurth wrote:
> > Combined reply to Jan and Roger
> > Lars
> >
> > On 03/07/2018, 11:07, "Roger Pau Monne" wrote:
> >
> > On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
> > > We then had
On 05/07/18 10:28, Jan Beulich wrote:
>
+/*
+ * Audit was successful. Replace existing policies, leaving the old
+ * policies to be freed.
+ */
+SWAP(new.cp, d->arch.cpuid);
+SWAP(new.dp, d->arch.msr);
+SWAP(new.vp, v->arch.msr);
On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
> ### Security Process
> *Batches and timing:* Everyone present, felt that informal batching is good
> (exception Doug G),
fwiw, I don't dislike the batching. I just complained when there's a lot
of items in the batch. We attempt to liv
On 05/07/18 19:25, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> I don’t really understand why you’re more worried about a test
>> corrupting a bac
On 05/07/18 14:51, Jan Beulich wrote:
> During early boot timestamps aren't very useful, as they're all zero
> (in "boot" mode) or absent altogether (in "date" and "datems" modes).
> Log "boot" format timestamps when the date formats aren't available yet,
> and log raw timestamps when boot ones are
George Dunlap writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> I don’t really understand why you’re more worried about a test
> corrupting a backup partition or LVM snapshot, than of a test
> On Jul 5, 2018, at 6:02 PM, Ian Jackson wrote:
>
> Andrew Cooper writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> XenRT, which is XenServers provisioning and testing system and in
On 05/07/18 19:11, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> Just wondering, are there any timing statistics kept for the OSStest
>> fligh
On 05/07/18 14:54, Jan Beulich wrote:
> --- a/xen/arch/x86/i387.c
> +++ b/xen/arch/x86/i387.c
> @@ -337,6 +337,49 @@ int vcpu_init_fpu(struct vcpu *v)
> return rc;
> }
>
> +void vcpu_load_fpu(struct vcpu *v, struct xsave_struct *xsave_area,
How about vcpu_setup_fpu() ? This function either
Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> Just wondering, are there any timing statistics kept for the OSStest
> flights (and separate for building the various comp
On 05/07/18 19:02, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> XenRT, which is XenServers provisioning and testing system and install,
>> can dep
flight 124997 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124997/
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
Andrew Cooper writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> XenRT, which is XenServers provisioning and testing system and install,
> can deploy arbitrary builds of XenServer, or arbitrar
Hi all,
please find attached information about the next x86 community call. As we have
made significant progress on most of the open issues, I wanted to start with a
clean slate from a topic’s perspective. In other words, let’s have a very quick
status update section and otherwise cover new top
On 05/07/18 17:41, George Dunlap wrote:
>
>> On Jul 5, 2018, at 5:23 PM, Ian Jackson wrote:
>>
>> Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018
>> design session] Process changes: is the 6 monthly release Cadence too short,
>> Security Process, ..."):
>>> Thursday, July
On Thu, Jul 5, 2018 at 4:44 AM Adrian Pop wrote:
>
> The p2m_access_to_xenmem_access() converts a p2m_access_t to a
> xenmem_access_t. It is complementary to xenmem_access_to_p2m_access().
> It is currently only used by _p2m_get_mem_access().
>
> Signed-off-by: Adrian Pop
> ---
> xen/arch/x86/m
On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru
wrote:
>
> On 07/05/2018 05:35 PM, Tamas K Lengyel wrote:
> > Jan's comment here about the too broad exposure is not without a
> > point. For a security application to point in using altp2m and
> > memaccess is to have memory protections that the gues
> On Jul 5, 2018, at 5:23 PM, Ian Jackson wrote:
>
> Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> Thursday, July 5, 2018, 5:14:39 PM, you wrote:
>>> So that m
Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> Thursday, July 5, 2018, 5:14:39 PM, you wrote:
> > So that means that often, and at least from one test flight to the
> >
This run is configured for baseline tests only.
flight 74937 xen-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74937/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstor
TYPE_XEN_PT_DEVICE is a subclass of TYPE_PCI_DEVICE, the clean way
to access the PCIDevice pointer is using the PCI_DEVICE() macro.
Suggested-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Acked-by: Anthony PERARD
Acked-by: Michael S. Tsirkin
---
hw/xe
Thursday, July 5, 2018, 5:14:39 PM, you wrote:
> Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> Same applies to the host: the base system (without the to be tested
>>
On 07/05/2018 07:16 AM, Peter Maydell wrote:
> On 4 July 2018 at 16:39, Philippe Mathieu-Daudé wrote:
>> Patch created mechanically by rerunning:
>>
>> $ spatch --sp-file scripts/coccinelle/typecast.cocci \
>> --macro-file scripts/cocci-macro-file.h \
>> --dir . --in-pla
On Thu, Jul 05, 2018 at 07:51:09AM -0600, Jan Beulich wrote:
> During early boot timestamps aren't very useful, as they're all zero
> (in "boot" mode) or absent altogether (in "date" and "datems" modes).
> Log "boot" format timestamps when the date formats aren't available yet,
> and log raw timest
Roger Pau Monne writes ("[PATCH 6/6] osstest: add FreeBSD Xen build job"):
...
> +create_freebsd_xen_build_job () {
> + job_create_build build-$arch-xen$xsm_suffix-freebsd build-xen-freebsd\
> +arch=$arch \
> +enable_xsm=$enab
On 07/05/2018 05:35 PM, Tamas K Lengyel wrote:
> Jan's comment here about the too broad exposure is not without a
> point. For a security application to point in using altp2m and
> memaccess is to have memory protections that the guest can't alter, so
> even if the guest kernel gets compromised, so
Roger Pau Monne writes ("[PATCH 5/6] osstest: set the make command to use for
xen-build"):
> 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.
Acked-by: Ian Jackson
__
Roger Pau Monne writes ("[PATCH 2/6] osstest: remove duplicate
set_freebsd_runvars"):
> 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
>
Roger Pau Monne writes ("[PATCH 4/6] osstest: limit FreeBSD jobs to hardware
booting in BIOS mode"):
> 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.
expects $arch to be set to the desired FreeBSD
Roger Pau Monne writes ("[PATCH 3/6] osstest: abstract code to create a FreeBSD
build job"):
> Into a helper.
I guess this is supposed to be NFC, but you don't say so. Have you
run standalone-generate-dump-flight-runvars and diffed the result
before and after ?
In general that's a good thing to
Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> Same applies to the host: the base system (without the to be tested
> component like qemu, xen, or whatever) could be installed
On Sun, Jun 17, 2018 at 03:18:15AM -0700, Joshua Otto wrote:
> From: Joshua Otto
>
> In write_batch() on the migration save side and in process_page_data()
> on the corresponding path on the restore side, a local variable named
> 'mfns' is used to refer to an array of what are actually gfns. Ren
On Thu, Jul 05, 2018 at 04:06:35PM +0100, Wei Liu wrote:
> On Tue, Jun 12, 2018 at 04:31:43PM +0300, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov
> [...]
> > diff --git a/tools/libxl/libxl_vkb.c b/tools/libxl/libxl_vkb.c
> > index 7652ad23ce..beaf17475d 100644
> > --- a/tools/libxl/libxl_v
On Tue, Jun 12, 2018 at 04:31:47PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Add parsing and adding to xen store following extended parameters:
> * feature-disable-keyboard
> * feature-disable-pointer
> * feature-abs-pointer
> * feature-multi-touch
> * feature-raw-pointer
> *
On Tue, Jun 12, 2018 at 04:31:43PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
[...]
> diff --git a/tools/libxl/libxl_vkb.c b/tools/libxl/libxl_vkb.c
> index 7652ad23ce..beaf17475d 100644
> --- a/tools/libxl/libxl_vkb.c
> +++ b/tools/libxl/libxl_vkb.c
> @@ -14,12 +14,42 @@
>
> #in
On Tue, Jun 12, 2018 at 06:40:46PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> In the display protocol connector's id is named as unique-id. This patch
> renames
> it in the libxl/xl code and uses XENDISPL_FIELD... definitions from the
> protocol
> header.
>
> Signed-off-by:
On Fri, Jun 15, 2018 at 01:15:15PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Add getting vsnd list and info API
>
> Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
htt
>>> On 05.07.18 at 16:08, wrote:
> On 05/07/18 10:08, Jan Beulich wrote:
> On 04.07.18 at 19:57, wrote:
>>> On 04/07/18 10:43, Jan Beulich wrote:
And with this I now
wonder whether the pointers in struct policy_group shouldn't all
be const qualified.
>>> Unfortunately that does
flight 124974 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124920
test-amd64-i386-xl-qemuu-o
On Thu, Jul 05, 2018 at 07:54:43AM -0600, Jan Beulich wrote:
> First of all introduce a helper function instead of replicating almost
> the same code for PV and HVM. The differences between the two pieces of
> code actually points out an issue (which is also addressed here): In
> the HVM case FCW w
On Thu, Jul 5, 2018 at 2:31 AM Jan Beulich wrote:
>
> >>> On 04.07.18 at 18:44, wrote:
>
> >
> >> On Jul 4, 2018, at 4:38 PM, Jan Beulich wrote:
> >>
> > On 04.07.18 at 16:05, wrote:
> On Jul 2, 2018, at 7:34 AM, Jan Beulich wrote:
> >>> On 29.06.18 at 18:39, wrote:
> > On 06
On Tue, 2018-07-03 at 21:55 +0100, Andrew Cooper wrote:
> From: Sergey Dyasli
>
> This finally (after literally years of work!) marks the point where the
> toolstack can ask the hypervisor for the current CPUID configuration of a
> specific domain.
>
> Also extend xen-cpuid's --policy mode to be
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
+build-amd6
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é
---
Note that this pa
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 duplication
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 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é
---
Changes since v1:
- Use gmake for all BSDs.
---
ts-xen-build | 11 ++-
1 file changed, 6 insertions(+)
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 ad
Into a helper.
Signed-off-by: Roger Pau Monné
---
make-freebsd-flight | 24 +---
mfi-common | 14 ++
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/make-freebsd-flight b/make-freebsd-flight
index 1a2b359c..6c530ebe 100755
--- a/make-free
On 05/07/18 10:08, Jan Beulich wrote:
On 04.07.18 at 19:57, wrote:
>> On 04/07/18 10:43, Jan Beulich wrote:
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -32,22 +32,32 @@
#include
const struct policy_group system_policies[] = {
-{
>>> On 05.07.18 at 15:39, wrote:
> On 05/07/18 09:40, Jan Beulich wrote:
> On 04.07.18 at 18:23, wrote:
>>> On 04/07/18 09:51, Jan Beulich wrote:
>>> On 04.07.18 at 10:42, wrote:
> On Tue, Jul 03, 2018 at 09:55:19PM +0100, Andrew Cooper wrote:
>> --- a/xen/include/public/arch-x86
First of all introduce a helper function instead of replicating almost
the same code for PV and HVM. The differences between the two pieces of
code actually points out an issue (which is also addressed here): In
the HVM case FCW would not have been set to FCW_RESET in certain cases
(note for exampl
During early boot timestamps aren't very useful, as they're all zero
(in "boot" mode) or absent altogether (in "date" and "datems" modes).
Log "boot" format timestamps when the date formats aren't available yet,
and log raw timestamps when boot ones are still all zero. Also add a
"raw" mode.
For t
On Wed, Jul 04, 2018 at 12:39:11PM -0300, Philippe Mathieu-Daudé wrote:
> Nothing exciting here, patches created mechanically
> (common after soft freeze).
Acked-by: Michael S. Tsirkin
> Philippe Mathieu-Daudé (8):
> qobject: Catch another straggler for use of qdict_put_str()
> error: Remove
flight 124942 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124942/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64
On 05/07/18 09:40, Jan Beulich wrote:
On 04.07.18 at 18:23, wrote:
>> On 04/07/18 09:51, Jan Beulich wrote:
>> On 04.07.18 at 10:42, wrote:
On Tue, Jul 03, 2018 at 09:55:19PM +0100, Andrew Cooper wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arc
>>> On 11.05.18 at 13:11, wrote:
> Signed-off-by: Alexandru Isaila
> ---
> xen/include/asm-x86/monitor.h | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index c5a86d1..7ef2aa2 100644
> --- a/x
On 05/07/18 09:46, Jan Beulich wrote:
On 04.07.18 at 18:46, wrote:
>> On 04/07/18 10:01, Jan Beulich wrote:
>> On 03.07.18 at 22:55, wrote:
--- a/xen/common/libx86/cpuid.c
+++ b/xen/common/libx86/cpuid.c
@@ -34,6 +34,100 @@ const uint32_t *x86_cpuid_lookup_deep_deps(uint32
>>> On 07.05.18 at 15:40, wrote:
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -84,7 +84,8 @@ static inline uint32_t arch_monitor_get_capabilities(struct
> domain *d)
> (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
>
>>> On 05.07.18 at 14:57, wrote:
> On 05/07/18 13:00, Jan Beulich wrote:
> On 05.07.18 at 11:59, wrote:
>>> On Tue, Jun 26, 2018 at 01:19:43AM -0600, Jan Beulich wrote:
When booting Xen via UEFI the Xen config file can contain multiple
sections each describing different boot options
On 05/07/18 13:00, Jan Beulich wrote:
On 05.07.18 at 11:59, wrote:
>> On Tue, Jun 26, 2018 at 01:19:43AM -0600, Jan Beulich wrote:
>>> When booting Xen via UEFI the Xen config file can contain multiple
>>> sections each describing different boot options. It is currently only
>>> possible to c
Hi all,
at some point we need to take a step back and summarize this discussion and
establish
a) what seems to be agreed
b) what is possible
c) and what is controversial
I am sort of volunteering for this and was planning to do so tomorrow.
Lars
On 05/07/2018, 13:20, "Juergen Gross" wrote:
On 05/07/18 13:51, Andrew Cooper wrote:
> On 05/07/18 12:18, George Dunlap wrote:
>>
Another potential problems showed up last week: OSSTEST is using the
Debian servers for doing the basic installation. A change there (e.g.
a new point release) will block tests. I'd prefer t
Hi,
I started to work on building Vagrant boxes for Xen, in order to
have reproducible environments when testing my VMI tools,
and try out the latest release without having to mess with my distro.
I want to share my work as it might be useful for other Xen developers as well:
https://github.com/W
>>> On 05.07.18 at 11:59, wrote:
> On Tue, Jun 26, 2018 at 01:19:43AM -0600, Jan Beulich wrote:
>> When booting Xen via UEFI the Xen config file can contain multiple
>> sections each describing different boot options. It is currently only
>> possible to choose which section to boot with if the buf
On 05/07/18 12:18, George Dunlap wrote:
>
>>>Another potential problems showed up last week: OSSTEST is using the
>>>Debian servers for doing the basic installation. A change there (e.g.
>>>a new point release) will block tests. I'd prefer to have a local cache
>>>of the last known
On 05/07/18 13:16, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> We didn't look at the sporadic failing tests thoroughly enough. The
>> hypercall b
> On Jul 5, 2018, at 12:16 PM, Ian Jackson wrote:
>
> Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> We didn't look at the sporadic failing tests thoroughly enough.
Wei Liu writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session]
Process changes: is the 6 monthly release Cadence too short, Security Process,
..."):
> It is more the case that one incomplete fix blocks all other valid
> fixes, so the time from staging to msater is even longer.
>
> (
Wei Liu writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session]
Process changes: is the 6 monthly release Cadence too short, Security Process,
..."):
> Osstest is really resource intense and heavy weight. We need to think of
> a way to reduce its turnaround time. Or we can introduce
> On Jul 5, 2018, at 12:05 PM, Ian Jackson wrote:
>
> Lars Kurth writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> * The Gitlab machinery will do build tests (and the discussion
>>
Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
session] Process changes: is the 6 monthly release Cadence too short, Security
Process, ..."):
> We didn't look at the sporadic failing tests thoroughly enough. The
> hypercall buffer failure has been there for ages, a newer
Lars Kurth writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session]
Process changes: is the 6 monthly release Cadence too short, Security Process,
..."):
> * The Gitlab machinery will do build tests (and the discussion
> showed that we should be able to do this via cross compilation
On 05/07/2018, 10:50, "Julien Grall" wrote:
On 05/07/18 10:48, Wei Liu wrote:
> On Mon, Jul 02, 2018 at 05:18:15PM +0100, Julien Grall wrote:
>> Hi Lars,
>>
>> It looks like this series has never been merged. Do you know that state
of
>> it?
>>
>> The
1 - 100 of 167 matches
Mail list logo
