On 07/06/18 03:55, osstest service owner wrote:
> flight 123831 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/123831/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
flight 123835 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123122
Tests which
flight 123831 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123831/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 broken
On 05/25/2018 01:07 AM, Jan Beulich wrote:
On 24.05.18 at 22:23, wrote:
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -11,6 +11,19 @@
#define BUG_ON(p) do { if (unlikely(p)) BUG(); } while (0)
#define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
+#define
flight 123823 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 broken
test-arm64-arm64-xl
flight 123828 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123828/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123797
test-armhf-armhf-libvirt-xsm 14
On Wed, Jun 06, 2018 at 05:51:38PM -0400, Boris Ostrovsky wrote:
> On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote:
> > On 06/05/2018 01:36 AM, Boris Ostrovsky wrote:
> >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko
> >>>
> >>> Allow creating
On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote:
> On 06/05/2018 01:36 AM, Boris Ostrovsky wrote:
>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Allow creating grant device context for use by kernel modules which
>>> require
On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:
> On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>> +
>> +static struct sg_table *
>> +dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *attach,
>> + enum
On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:
> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>> +struct gntdev_dmabuf_export_args {
>> + int dummy;
>> +};
>>
>> Please define the full structure (at least what you have in the
On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
> On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>> @@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map)
>> if (map == NULL)
>> return;
>> +#ifdef
On 06/06/2018 03:24 AM, Oleksandr Andrushchenko wrote:
> On 06/04/2018 07:37 PM, Boris Ostrovsky wrote:
>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>>> diff --git a/include/xen/mem-reservation.h
>>> b/include/xen/mem-reservation.h
>>> new file mode 100644
>>> index
This run is configured for baseline tests only.
flight 74792 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74792/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 91c31ff04a7a72b4b0e476972ad3c76e03a106a2
baseline
flight 74786 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74786/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74761
flight 123820 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123820/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 15 leak-check/check fail REGR. vs. 123447
Tests which did not
(+ Stefano, Mirela, Juergen and Boris)
On 06/06/18 09:17, moin anjnawala wrote:
Hi Julien,
Hi,
As you specified earlier I am now able to boot using xen4.10. I am
using linux4.4 as dom0 as well as domU.In domU, I have enabled
hibenation related configs and I am trying suspend to disk.With
On Wed, Jun 06, 2018 at 04:59:24PM +0100, Andrew Cooper wrote:
> On 06/06/18 16:49, Roger Pau Monné wrote:
> > On Mon, Jun 04, 2018 at 02:59:08PM +0100, Andrew Cooper wrote:
> >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> >> index 10415e6..7fddae1 100644
> >> ---
On Tue, Jun 05, 2018 at 11:55:36AM +0200, Roger Pau Monne wrote:
> Add a note to spell out that if the address tag is not present the
> file should be loaded using the elf header.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Daniel Kiper
> Cc: xen-devel@lists.xenproject.org
> ---
>
On Mon, Jun 04, 2018 at 02:59:15PM +0100, Andrew Cooper wrote:
> Replace the few remaining uses with X86_DR6_* constants.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Mon, Jun 04, 2018 at 02:59:13PM +0100, Andrew Cooper wrote:
> The current logic used to update %dr6 when injecting #DB is buggy. The
> architectural behaviour is to overwrite B{0..3} (rather than accumulate) and
> accumulate all other bits.
>
> Introduce a new merge_dr6() helper, which also
On Wed, Jun 06, 2018 at 05:50:38PM +0100, Andrew Cooper wrote:
> On 06/06/18 17:46, Roger Pau Monné wrote:
> > On Mon, Jun 04, 2018 at 02:59:11PM +0100, Andrew Cooper wrote:
> >> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> >> index bfa3a0d..39c9ddc 100644
> >> ---
On Mon, Jun 04, 2018 at 02:59:12PM +0100, Andrew Cooper wrote:
> Currently, there is a lot of functionality in the #DB intercepts, and some
> repeated functionality in the *_inject_event() logic.
>
> The gdbsx code is implemented at both levels (albeit differently for #BP,
> which is presumably
flight 123819 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 122969
On 06/06/18 17:46, Roger Pau Monné wrote:
> On Mon, Jun 04, 2018 at 02:59:11PM +0100, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index bfa3a0d..39c9ddc 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2483,7
On Mon, Jun 04, 2018 at 02:59:11PM +0100, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index bfa3a0d..39c9ddc 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2483,7 +2483,7 @@ void update_guest_eip(void)
> }
>
On Wed, 6 Jun 2018, Jan Beulich wrote:
> >>> On 04.06.18 at 19:24, wrote:
> > --- a/xen/arch/Kconfig
> > +++ b/xen/arch/Kconfig
> > @@ -3,6 +3,10 @@ config NR_CPUS
> > int "Maximum number of physical CPUs"
> > range 1 4095
> > default "256" if X86
> > + default "128" if ARM && ALL
>
On Mon, Jun 04, 2018 at 02:59:10PM +0100, Andrew Cooper wrote:
> Reusing debugreg[5] for the PV emulated IO breakpoint information is confusing
> to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
>
> With the PV emulation out of the way, debugreg[4,5] are entirely unused
Anthony PERARD writes ("Re: [Xen-devel] [OSSTEST PATCH 3/3] mfi-*: Set
appropriate PropMinVer:XenMin: hostflags, to honour XenMin property"):
> On Wed, Jun 06, 2018 at 12:04:56PM +0100, Ian Jackson wrote:
> > @@ -566,6 +573,13 @@ test_matrix_iterate () {
> > if [ "x$min_linux_hostflag"
On 06/06/18 16:49, Roger Pau Monné wrote:
> On Mon, Jun 04, 2018 at 02:59:08PM +0100, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 10415e6..7fddae1 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -977,6 +977,7 @@
On Mon, Jun 04, 2018 at 02:59:09PM +0100, Andrew Cooper wrote:
> No functional change (as curr->arch.debugreg[5] is zero when DE is clear), but
> this change simplifies the following patch.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
On Mon, Jun 04, 2018 at 02:59:08PM +0100, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 10415e6..7fddae1 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -977,6 +977,7 @@ unsigned long hvm_cr4_guest_valid_bits(const struct
>
On 06/06/18 16:00, Jan Beulich wrote:
On 04.06.18 at 15:59, wrote:
>> @@ -981,9 +981,14 @@ int arch_set_info_guest(
>> v->arch.pv_vcpu.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(v, cr4) :
>> real_cr4_to_pv_guest_cr4(mmu_cr4_features);
>>
>> -memset(v->arch.debugreg, 0,
>>> On 06.06.18 at 16:50, wrote:
> On 06/06/18 15:16, Jan Beulich wrote:
>>> +dr6 |= 0xfffe0ff0 | (rtm ? 0 : X86_DR6_RTM);
>>> +dr6 &= 0xefff;
>> I'm not overly happy with this move to literal numbers. Could we
>> at least meet in the middle and adjust the first line to
>>
>> dr6
On Wed, Jun 06, 2018 at 12:04:56PM +0100, Ian Jackson wrote:
> @@ -566,6 +573,13 @@ test_matrix_iterate () {
> if [ "x$min_linux_hostflag" != "x" ] ; then
> most_hostflags="$most_hostflags,$min_linux_hostflag"
> fi
> +case "$xenbranch" in
> +
flight 123817 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 122997
>>> On 04.06.18 at 15:59, wrote:
> @@ -981,9 +981,14 @@ int arch_set_info_guest(
> v->arch.pv_vcpu.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(v, cr4) :
> real_cr4_to_pv_guest_cr4(mmu_cr4_features);
>
> -memset(v->arch.debugreg, 0, sizeof(v->arch.debugreg));
> -for ( i = 0; i <
Hello all,
I have been tasked with the issue of UEFI NVRAM variable retention
with Xen HVM/OVMF based guests and wanted to consult the experts before
I undertake any significant coding effort. I am new to Xen so any
help/direction would be appreciated.
What I hope to gain from this
On 06/06/18 15:50, Andrew Cooper wrote:
> On 06/06/18 15:16, Jan Beulich wrote:
>>> +dr6 |= 0xfffe0ff0 | (rtm ? 0 : X86_DR6_RTM);
>>> +dr6 &= 0xefff;
>> I'm not overly happy with this move to literal numbers. Could we
>> at least meet in the middle and adjust the first line to
>>
>>
On 06/06/18 15:16, Jan Beulich wrote:
>> +dr6 |= 0xfffe0ff0 | (rtm ? 0 : X86_DR6_RTM);
>> +dr6 &= 0xefff;
> I'm not overly happy with this move to literal numbers. Could we
> at least meet in the middle and adjust the first line to
>
> dr6 |= X86_DR6_DEFAULT & ~(rtm ? 0 :
>>> On 04.06.18 at 15:59, wrote:
> No functional change (as curr->arch.debugreg[5] is zero when DE is clear), but
> this change simplifies the following patch.
A comment to this effect would be helpful ...
> --- a/xen/arch/x86/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate.c
> @@ -101,23
On 06/06/18 14:50, Jan Beulich wrote:
On 04.06.18 at 15:59, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3696,6 +3696,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> */
>> __vmread(EXIT_QUALIFICATION,
>>> On 04.06.18 at 15:59, wrote:
> The reserved bit calculations for %dr6 and %dr7 depend on whether the VM has
> the Restricted Transnational Memory feature available.
Transactional, I think.
> --- a/xen/include/asm-x86/debugreg.h
> +++ b/xen/include/asm-x86/debugreg.h
> @@ -10,9 +10,18 @@
>
On Mi, 2018-06-06 at 06:38 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 06.06.18 at 14:24, wrote:
> > @@ -394,7 +380,7 @@ static int vmce_load_vcpu_ctxt(struct domain
> > *d, hvm_domain_context_t *h)
> > return err ?: vmce_restore_vcpu(v, );
> > }
> >
> >
>>> On 04.06.18 at 15:59, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -322,6 +322,14 @@ void free_vcpu_struct(struct vcpu *v)
> free_xenheap_page(v);
> }
>
> +static void initialise_registers(struct vcpu *v)
> +{
> +v->arch.user_regs.eflags =
>>> On 04.06.18 at 15:59, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3696,6 +3696,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> */
> __vmread(EXIT_QUALIFICATION, _qualification);
> HVMTRACE_1D(TRAP_DEBUG,
>>> On 04.06.18 at 15:59, wrote:
> * State adjustments (and debug tracing) for #DB/#BP/#PF should not be done
>for `int $n` instructions. Updates to %cr2 occur even if the exception
>combines to #DF.
> * Don't opencode DR_STEP when updating %dr6.
> * Simplify the logic for calling
>>> On 04.06.18 at 19:24, wrote:
> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -3,6 +3,10 @@ config NR_CPUS
> int "Maximum number of physical CPUs"
> range 1 4095
> default "256" if X86
> + default "128" if ARM && ALL
With this dropped, as suggested by Julien, and
Hello,
Please use scripts/get_maintainers.pl to CC all the relevant maintainers
on your patch.
Regarding the title, Xen is supporting multiple architecture. So it is
always useful to specify the architecture in the title.
Also the title is quite confusing as for clearing interrupts, you
On 06/05/2018 01:36 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the
On 06/05/2018 01:28 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
/* -- */
+static int
+dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
+ int
>>> On 06.06.18 at 14:24, wrote:
> @@ -394,7 +380,7 @@ static int vmce_load_vcpu_ctxt(struct domain *d,
> hvm_domain_context_t *h)
> return err ?: vmce_restore_vcpu(v, );
> }
>
> -HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
> +HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU,
On Mi, 2018-06-06 at 12:33 +, Paul Durrant wrote:
> >
> > -Original Message-
> > From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> > Sent: 06 June 2018 13:25
> > To: xen-de...@lists.xen.org
> > Cc: Ian Jackson ; Wei Liu > com>;
> > jbeul...@suse.com; Andrew Cooper ; Paul
> >
>>> On 29.05.18 at 16:58, wrote:
> This patch is focused on merging the *save() funcs to the *save_one()
> funcs to remove redundancy. Also the for loop is moved to the caller so
> now we can save info for a single vcpu instance.
>
> Signed-off-by: Alexandru Isaila
>
> ---
> Changes since V4:
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 06 June 2018 13:25
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v6 7/8] x86/hvm: Introduce
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/hvm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c23983c..76f7db9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++
This patch is focused on merging the *save() funcs to the *save_one()
funcs to remove redundancy. Also the for loop is moved to the caller so
now we can save info for a single vcpu instance.
Signed-off-by: Alexandru Isaila
---
Changes since V5:
- Removed err var and return the
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/cpu/mcheck/vmce.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index e07cd2f..404f27e
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V5:
- Check the return value of hvm_save_cpu_msrs_one()
---
xen/arch/x86/hvm/hvm.c | 60 --
1 file changed, 34 insertions(+), 26
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V5:
- Add memset to 0 for ctxt->_pad
---
xen/arch/x86/hvm/viridian.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian.c
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/hvm.c | 195 +
1 file changed, 100 insertions(+), 95 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/hvm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b254378..e8ecabf 100644
--- a/xen/arch/x86/hvm/hvm.c
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/mtrr.c | 52 +++--
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index
On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing
flight 123829 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123829/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 91c31ff04a7a72b4b0e476972ad3c76e03a106a2
baseline version:
ovmf
>>> On 06.06.18 at 13:04, wrote:
> The motivation right now for this is that Xen 4.10 and earlier do not
> boot xen.gz on UEFI. In earlier versions, one has to chainload
> xen.efi. We don't support that in osstest right now on x86 (and it
> probably isn't worth fixing that logic).
This is 4.8
flight 123812 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 123144
From: Ian Jackson
I have run standalone-generate-dump-flight-runvars and eyeballed the
(substantial) output, and it looks plausible.
Ian Jackson (3):
mfi-*: Reformat/refactor migrupgrade test generation slightly
mfi-*: Provide hostflags_strip
mfi-*: Set appropriate PropMinVer:XenMin:
* Introduce a variable "$hf" containing the hostflags.
* Properly indent the job_create_test call.
No functional change. This will make the substantive change easier to
read.
Signed-off-by: Ian Jackson
---
make-flight | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
* In test_matrix_iterate, where most_hostflags is set, include a
PropMinVer:XenMin: hostflag. This is derived from $xenbranch.
When $xenbranch is xen-unstable, don't add that hostflag.
* But this is wrong for the migrate upgrade tests, which use both this
and the previous version of Xen.
This utility function saves us having to fragment the *_hostflags
variables any further when adding special cases. A particular special
case can strip out things it doesn't like.
No callers yet.
Signed-off-by: Ian Jackson
---
mfi-common | 10 ++
1 file changed, 10 insertions(+)
diff
On Mon, Jun 04, 2018 at 02:59:07PM +0100, Andrew Cooper wrote:
> In particular, initialising %dr6 with the value 0 is buggy, because on
> hardware supporting Transnational Memory, it will cause the sticky RTM bit to
> be asserted, even though a debug event from a transaction hasn't actually been
>
On Mon, Jun 04, 2018 at 02:59:06PM +0100, Andrew Cooper wrote:
> c/s 4f36452b63 introduced a write to %dr6 in the #DB intercept case, but the
> guests debug registers may be lazy at this point, at which point the guests
> later attempt to read %dr6 will discard this value and use the older stale
>
On 06/06/18 10:45, Roger Pau Monné wrote:
> On Mon, May 28, 2018 at 03:27:57PM +0100, Andrew Cooper wrote:
>> paging_update_paging_modes() and vmx_vlapic_msr_changed() both operate on the
>> VMCS being constructed. Avoid dropping and re-acquiring the reference
>> multiple times.
>>
>>
Hi,
On 05/06/18 19:26, Lars Kurth wrote:
On 05/06/2018, 19:15, "Juergen Gross" wrote:
On 05/06/18 18:39, Julien Grall wrote:
> The option -f of scripts/get_maintainers.pl will return the maintainers
> of a given file, *not* the list of maintainers if the file was a patch.
On Mon, May 28, 2018 at 03:27:58PM +0100, Andrew Cooper wrote:
> The hvmloader code which used this signal was deleted 10 years ago (c/s
> 50b12df83 "x86 vmx: Remove vmxassist"). Furthermore, the value gets discarded
> anyway because the HVM domain builder unconditionally sets %rax to 0 in the
>
On Mon, May 28, 2018 at 03:27:57PM +0100, Andrew Cooper wrote:
> paging_update_paging_modes() and vmx_vlapic_msr_changed() both operate on the
> VMCS being constructed. Avoid dropping and re-acquiring the reference
> multiple times.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
>
On Mon, May 28, 2018 at 03:27:56PM +0100, Andrew Cooper wrote:
> The host PAT value is a compile time constant, and doesn't need to be read out
> of hardware. Merge this if block into the previous block, which has an
> identical condition.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger
On 06/06/18 11:35, Jan Beulich wrote:
On 05.06.18 at 18:19, wrote:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2
>>
>> I thought I would reply again with the key point from my earlier mail
>> highlighted, and go a bit further. The first thing to go wrong in
On Mon, May 28, 2018 at 03:27:55PM +0100, Andrew Cooper wrote:
> With the removal of the 32bit hypervisor build, host_pat is a constant value.
> Drop the variable and the redundant cpu_has_pat predicate, and use a define
> instead.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
flight 123848 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123848/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 3960f3a52346348e6b0306f65d19375612bd35b9
baseline version:
xen
>>> On 05.06.18 at 18:19, wrote:
>> > test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2
>
> I thought I would reply again with the key point from my earlier mail
> highlighted, and go a bit further. The first thing to go wrong in
> this was:
>
> 2018-05-30
On 05/06/18 22:34, Andrew Cooper wrote:
> On 05/06/2018 21:28, osstest service owner wrote:
>> flight 123799 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/123799/
>>
>> Failures and problems with tests :-(
>>
>> Tests which did not succeed and are blocking,
>>
>>> On 05.06.18 at 19:52, wrote:
>
> On 04/06/18 18:23, Stefano Stabellini wrote:
>> Hi all,
>>
>> This patch series is the first step toward building a small certifiable
>> Xen hypervisor for ARM boards.
>>
>> First, the series makes a few changes to allow disabling more kconfig
>> options:
>>> On 05.06.18 at 19:12, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -17,6 +17,9 @@ config HAS_ALTERNATIVE
> config HAS_DEVICE_TREE
> bool
>
> +config HAS_ELF
> +bool
> +
HAS_LIBELF (or NEEDS_LIBELF) would seem better to me.
Also please not the difference in
On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf
flight 123825 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123825/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf e6239ef65f546a2b08dc9f6f94bdcc880690ea29
baseline version:
xtf
Hi Julien,
As you specified earlier I am now able to boot using xen4.10. I am
using linux4.4 as dom0 as well as domU.In domU, I have enabled
hibenation related configs and I am trying suspend to disk.With xen
4.10, hibernation is done sucessfuly but resume crashes.
I have used given config file
On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also
On 06/04/2018 09:46 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting
On 05/06/18 18:16, Ian Jackson wrote:
> 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14 = Bad
> address): Internal error
This is worrying me.
The message is issued as a result of xc_get_pfn_type_batch() failing.
I see no other possibility for the failure with errno being
This run is configured for baseline tests only.
flight 74784 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74784/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 11
On 06/04/2018 07:37 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h
new file mode 100644
index ..a727d65a1e61
--- /dev/null
+++ b/include/xen/mem-reservation.h
@@ -0,0 +1,65
flight 123809 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 broken in 123492
93 matches
Mail list logo
