> > Bug detailed description:
> >
> > Can not boot up xen with new Domain0 kernel(linux5.4.0-rc3)
> >
> > Environment :
> >
> > HW: Cascade Lake server
> > Xen: XEN 4.13.0rc1
> > Dom0: Linux 5.4.0-rc3
> >
> > Reproduce steps:
> >
> > 1. install Xen
On 05.11.19 05:38, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable ch
On 05.11.19 02:30, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes (a range that is not
IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., se
On 05.11.19 10:17, David Hildenbrand wrote:
On 05.11.19 05:38, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
int
On 05.11.19 10:49, David Hildenbrand wrote:
On 05.11.19 10:17, David Hildenbrand wrote:
On 05.11.19 05:38, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use cas
On 04.11.19 23:44, Boris Ostrovsky wrote:
On 10/24/19 8:09 AM, David Hildenbrand wrote:
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 4f2e78a5e4db..af69f057913a 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -374,6 +374,13 @@ static void xen_online_page(stru
Am Fri, 27 Sep 2019 18:17:12 +0100
schrieb Ian Jackson :
> Olaf Hering writes ("[PATCH v1] libxl: fix crash in helper_done due to
> uninitialized data"):
> > A crash in helper_done, called from libxl_domain_suspend, was reported,
> > libxl_aoutils.c:328:datacopier_writable: unexpected poll event
On 01/11/2019 20:25, Andrew Cooper wrote:
> We cache Long Mode and No Execute early on boot, so take the opportunity to
> cache HYPERVISOR early as well.
Either:
1. the description needs clarifying that the whole 1c featureset is
being stored, or
2. a mask should be applied to store only the hy
On 05.11.19 02:37, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable ch
On Wed, Oct 23, 2019 at 03:22:24PM +0200, Jan Beulich wrote:
> On 21.10.2019 12:00, Roger Pau Monné wrote:
> > On Mon, Sep 30, 2019 at 04:00:42PM +0100, Wei Liu wrote:
> >> --- a/xen/include/asm-x86/guest/hypervisor.h
> >> +++ b/xen/include/asm-x86/guest/hypervisor.h
> >> @@ -36,6 +36,7 @@ bool hyp
On Mon, Nov 04, 2019 at 03:30:47PM +, Anthony PERARD wrote:
> Before 93dcc22, error from setting the vnc password to an empty
> string, when QEMU wasn't expected a password, never prevented the creation
> of a guest, and only logged an error message.
>
> Reported-by: Roger Pau Monné
> Fixes:
flight 143630 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143630/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142947
test-amd64-i386-xl-r
At this moment the default_access param from xc_altp2m_create_view is
not used.
This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/hvm.c| 3 ++-
xen/arch/x86/mm/p2m-ept.c
By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not brake in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for co
Add DornerWorks internal list. This will forward to relevant people
within DornerWorks.
Add myself to MAINTAINERS for ARINC653 scheduler.
Remove Robbie from MAINTAINERS for ARINC653 scheduler.
---
Note that get_maintainers.pl/add_maintainers.pl do not currently add
the DornerWorks list email ad
flight 143610 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142849
test-amd64-amd64-lib
From: Philippe Mathieu-Daudé
The Plug & Play region of the AHB/APB bridge can be accessed
by various word size, however the implementation is clearly
restricted to 32-bit:
static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
{
APBPnp *apb_pnp = GRLIB_APB_PNP(o
From: "Dr. David Alan Gilbert"
'the' has a tendency to double up; squash them back down.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Alex Bennée
Reviewed-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20191104185202.102504-1-dgilb...@redhat.com>
Signed-off-by: Lau
From: Philippe Mathieu-Daudé
Guests can crash QEMU when writting to PnP registers:
$ echo 'writeb 0x800ff042 69' | qemu-system-sparc -M leon3_generic -S -bios
/etc/magic -qtest stdio
[I 1571938309.932255] OPENED
[R +0.063474] writeb 0x800ff042 69
Segmentation fault (core dumped)
(gdb
From: Greg Kurz
The error message in object_class_property_add() was copied from
object_property_add() in commit 16bf7f522a2ff. Clarify that it is
about a class, not an object.
While here, have the format string in both functions to fit in a
single line for better grep-ability, despite the check
ial-branch-pull-request
for you to fetch changes up to a37a36a11b584e083b1c578f1d60e6e0f7878d5f:
global: Squash 'the the' (2019-11-05 15:06:09 +0100)
Tri
On 01.11.19 19:26, Jason Gunthorpe wrote:
On Mon, Oct 28, 2019 at 05:10:25PM -0300, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are tu
On Tue, Nov 05, 2019 at 08:51:52AM -0500, Stewart Hildebrand wrote:
> Add DornerWorks internal list. This will forward to relevant people
> within DornerWorks.
>
> Add myself to MAINTAINERS for ARINC653 scheduler.
>
> Remove Robbie from MAINTAINERS for ARINC653 scheduler.
>
Missing SoB here.
N
On Tue, Nov 5, 2019 at 5:43 AM Alexandru Stefan ISAILA
wrote:
>
> At this moment the default_access param from xc_altp2m_create_view is
> not used.
>
> This patch assigns default_access to p2m->default_access at the time of
> initializing a new altp2m view.
>
> Signed-off-by: Alexandru Isaila
Re
On 11/4/19 9:31 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
>> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
>>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
>>> *vma)
>>> struct gntdev_priv *priv = file->private_data;
On Tue, Nov 5, 2019 at 5:43 AM Alexandru Stefan ISAILA
wrote:
>
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not brake in case
> of a error and it is
flight 143689 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143689/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8d3f428109623096cb8845779cdf9dc44949b8e9
baseline version:
ovmf e2fc50812895b17e8b23f
On 05.11.2019 17:18, Tamas K Lengyel wrote:
> On Tue, Nov 5, 2019 at 5:43 AM Alexandru Stefan ISAILA
> wrote:
>>
>> By default the sve bits are not set.
>> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
>> to set a range of sve bits.
>> The core function, p2m_set_suppress_ve_
On Tuesday, November 5, 2019 10:09 AM, Wei Liu wrote:
>On Tue, Nov 05, 2019 at 08:51:52AM -0500, Stewart Hildebrand wrote:
>> Add DornerWorks internal list. This will forward to relevant people
>> within DornerWorks.
>>
>> Add myself to MAINTAINERS for ARINC653 scheduler.
>>
>> Remove Robbie from M
On 11/5/19 12:43 PM, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not brake in case
> of a error and it is doing a best
This is needed for more precise patchability verification.
Only non-special .rodata sections should be subject
for such a non-referenced check in kpatch_verify_patchability().
Current check (non-standard, non-rela, non-debug) is too weak and
allows also non-rodata sections without referenced symbol
The rela groups in the *.fixup sections vary in size. That makes it
more complex to handle in the livepatch_strip_undefined_elements().
It is also unnecessary as the .fixup sections are unlikely to have
any STN_UNDEF symbols anyway.
Signed-off-by: Pawel Wieczorkiewicz
---
create-diff-object.c |
On 11/5/19 12:43 PM, Alexandru Stefan ISAILA wrote:
> At this moment the default_access param from xc_altp2m_create_view is
> not used.
Weird!
>
> This patch assigns default_access to p2m->default_access at the time of
> initializing a new altp2m view.
>
> Signed-off-by: Alexandru Isaila
Acke
>>
>> +/*
>> + * Set/clear the #VE suppress bit for multiple pages. Only available on
>> VMX.
>> + */
>> +long p2m_set_suppress_ve_multi(struct domain *d, uint32_t start, uint32_t
>> nr,
>> + bool suppress_ve, unsigned int altp2m_idx)
>> +{
>> +struct p2m_do
On 05.11.2019 17:38, George Dunlap wrote:
> On 11/5/19 12:43 PM, Alexandru Stefan ISAILA wrote:
>> At this moment the default_access param from xc_altp2m_create_view is
>> not used.
>
> Weird!
Indeed, it was bugging me every time I passed throughout that code.
Alex
>
>>
>> This patch assigns
Patchew URL: https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PULL 0/4] Trivial branch patches
Type: series
Message-id: 20191105144247.10301-1-laur...@vivier.eu
=== TES
Greg, Dave,
could you fix that?
Thanks,
Laurent
Le 05/11/2019 à 16:48, no-re...@patchew.org a écrit :
> Patchew URL:
> https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more informa
On Tue, Nov 05, 2019 at 11:02:46AM +0100, David Hildenbrand wrote:
> On 05.11.19 10:49, David Hildenbrand wrote:
> >On 05.11.19 10:17, David Hildenbrand wrote:
> >>On 05.11.19 05:38, Dan Williams wrote:
> >>>On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVI
Den 05.11.2019 02:15, skrev Andrew Cooper:
On 05/11/2019 00:25, Andrew Cooper wrote:
On 04/11/2019 23:42, Andrew Cooper wrote:
On 04/11/2019 23:20, Håkon Alstadheim wrote:
(XEN) RFLAGS=0x0193 (0x0193) DR7 = 0x0400
(XEN) *** Insn bytes from b8868f61d69a: 44 00 00 8c d
* Laurent Vivier (laur...@vivier.eu) wrote:
> Greg, Dave,
>
> could you fix that?
>
> Thanks,
> Laurent
>
> Le 05/11/2019 à 16:48, no-re...@patchew.org a écrit :
> > Patchew URL:
> > https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/
> >
> >
> >
> > Hi,
> >
> > This series s
On 11/5/19 5:18 AM, David Hildenbrand wrote:
> On 04.11.19 23:44, Boris Ostrovsky wrote:
>> On 10/24/19 8:09 AM, David Hildenbrand wrote:
>>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>>> index 4f2e78a5e4db..af69f057913a 100644
>>> --- a/drivers/xen/balloon.c
>>> +++ b/drivers/xen/
Le 05/11/2019 à 17:03, Dr. David Alan Gilbert a écrit :
> * Laurent Vivier (laur...@vivier.eu) wrote:
>> Greg, Dave,
>>
>> could you fix that?
>>
>> Thanks,
>> Laurent
>>
>> Le 05/11/2019 à 16:48, no-re...@patchew.org a écrit :
>>> Patchew URL:
>>> https://patchew.org/QEMU/20191105144247.10301-1-l
flight 143600 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143600/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142932
test-amd64-amd64-lib
ial-branch-pull-request
for you to fetch changes up to e187e55ec65039ed6bd982debee632450ace3bae:
global: Squash 'the the' (2019-11-05 18:39:14 +0100)
Trivia
From: Philippe Mathieu-Daudé
Guests can crash QEMU when writting to PnP registers:
$ echo 'writeb 0x800ff042 69' | qemu-system-sparc -M leon3_generic -S -bios
/etc/magic -qtest stdio
[I 1571938309.932255] OPENED
[R +0.063474] writeb 0x800ff042 69
Segmentation fault (core dumped)
(gdb
From: "Dr. David Alan Gilbert"
'the' has a tendency to double up; squash them back down.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Alex Bennée
Reviewed-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20191104185202.102504-1-dgilb...@redhat.com>
Signed-off-by: Lau
From: Philippe Mathieu-Daudé
The Plug & Play region of the AHB/APB bridge can be accessed
by various word size, however the implementation is clearly
restricted to 32-bit:
static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
{
APBPnp *apb_pnp = GRLIB_APB_PNP(o
Patchew URL: https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PULL 0/4] Trivial branch patches
Type: series
Message-id: 20191105144247.10301-1-laur...@vivier.eu
=== TES
flight 143646 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143646/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 139698
test-amd64-amd64-libv
Patchew URL: https://patchew.org/QEMU/20191105175010.2591-1-laur...@vivier.eu/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Xen-devel] [PULL v2 0/3] Trivial branch patches
Type: series
Message-id: 20191105175010.2591-1-laur...@vivie
The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true. The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different vcpu.
This case is rare, and can be worked aro
This pair of patches is long overdue being posted upstream. For several years
now, XenServer has shipped the 2nd patch as a safety check (seeing as we have
both livepatching and introspection), implemented with some return address
manipulation to turn a void load hook into one which can return -EB
One use of load hooks is to perform a safety check of the system in its
quiesced state. Any non-zero return value from a load hook will abort the
apply attempt.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
CC: Juergen Gross
For several years, the following pa
flight 143581 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143581/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
test-amd64-i38
The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true. The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different vcpu.
This case is rare, and can be worked aro
Le 05/11/2019 à 20:20, no-re...@patchew.org a écrit :
> Patchew URL: https://patchew.org/QEMU/20191105175010.2591-1-laur...@vivier.eu/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Subject: [Xen-devel] [PULL v2 0/3] Trivial b
I think I know what's going wrong:
Pages that are pinned via gfn_to_pfn() and friends take a references,
however are often released via
kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean()...
E.g., in arch/x86/kvm/x86.c:reexecute_instruction()
...
pfn = gfn_to_pfn(vcpu->kvm
flight 143704 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143704/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Now that we have KERNEL_HEADER_TEST all headers are generally compile
> tested, so relying on makefile tricks to avoid compiling code that depends
> on CONFIG_MMU_NOTIFIER is more annoying.
>
> Instead follow the usual patte
On 2019-11-04 07:13, Daniel Kiper wrote:
> Hi,
>
> Due to very limited space in the setup_header this patch series introduces new
> kernel_info struct which will be used to convey information from the kernel to
> the bootloader. This way the boot protocol can be extended regardless of the
> setup_
On Tue, Nov 05, 2019 at 09:30:53PM +0100, David Hildenbrand wrote:
> >>>I think I know what's going wrong:
> >>>
> >>>Pages that are pinned via gfn_to_pfn() and friends take a references,
> >>>however are often released via
> >>>kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean
On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
>
> >>> I think I know what's going wrong:
> >>>
> >>> Pages that are pinned via gfn_to_pfn() and friends take a references,
> >>> however are often released via
> >>> kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean().
On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
> > > The scarier code (for me) is transparent_hugepage_adjust() and
> > > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the
> > > interaction between THP and _PA
On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
wrote:
>
> On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
> > > > The scarier code (for me) is transparent_hugepage_adjust() and
> > > > kvm_mmu_zap_collapsible_spte(), a
flight 143677 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 143190
test-amd64-amd
On Tue, Nov 05, 2019 at 03:30:00PM -0800, Dan Williams wrote:
> On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> wrote:
> >
> > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand
> > > wrote:
> > > > > The scarier code (for m
On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote:
>
> On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> wrote:
> >
> > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand
> > > wrote:
> > > > > The scarier code (for me) is tr
+ xen-devel
On Tue, 5 Nov 2019, Stefano Stabellini wrote:
> Actually, pygrub cross-compiles without issues. The cross-compilation
> work-around goes back to 2005 and it probably referred to PowerPC.
>
> Remove the work-around now.
>
> Signed-off-by: Stefano Stabellini
> CC: Christopher Clark
>
Hi Dario,
I just checked and the patch is not in staging yet. Can we please make
sure the patch goes in as soon as possible, given the looming release?
Cheers,
Stefano
-- Forwarded message --
Date: Mon, 28 Oct 2019 11:40:23 -0700 (PDT)
From: Stefano Stabellini
To: Dario Faggiol
On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote:
> On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote:
> >
> > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> > wrote:
> > >
> > > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > > > On Tue, Nov 5, 2019 at 12:31 P
On Tue, Nov 5, 2019 at 4:03 PM Sean Christopherson
wrote:
>
> On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote:
> > On Tue, Nov 5, 2019 at 3:30 PM Dan Williams
> > wrote:
> > >
> > > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> > > wrote:
> > > >
> > > > On Tue, Nov 05, 2019
flight 143729 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 139091
test-amd64-amd
flight 143721 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143721/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 08a19af3c78e8a03f83bc354b50545136c03edd2
baseline version:
xtf 1b74ec3374a6edf32f
From: "julian.tumin...@gmail.com"
Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range. However, this
is not scalable to all version of Windows as it w
flight 143733 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail
REGR. vs. 138829
On 06.11.19 01:08, Dan Williams wrote:
On Tue, Nov 5, 2019 at 4:03 PM Sean Christopherson
wrote:
On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote:
On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote:
On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
wrote:
On Tue, Nov 05, 201
76 matches
Mail list logo
