>>> On 02.02.17 at 23:46, wrote:
> Since c/s eee5909e9d (x86/EFI: use less crude a way of generating the
> build ID) builds have been broken when using GNU Make 4.1. This is
> because there are no dependencies on buildid.o and as such GNU Make does
> not build it. This adds a dependency so that it
>>> On 02.02.17 at 20:25, wrote:
> @@ -261,6 +265,8 @@ GLOBAL(init_secondary)
> sub x20, x19, x0 /* x20 := phys-offset */
>
> mov x22, #1/* x22 := is_secondary_cpu */
> +/* Skip zero BSS on secondary CPUs to avoid nasty surprises. */
> +
On 26/01/17 20:41, Boris Ostrovsky wrote:
> Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
> page, initialize boot_params, enable early page tables.
>
> Since this stub is executed before kernel entry point we cannot use
> variables in .bss which is cleared by kernel. We expl
>>> On 02.02.17 at 18:12, wrote:
> On Thu, Feb 02, 2017 at 10:01:46AM -0700, Jan Beulich wrote:
>> >>> On 02.02.17 at 17:50, wrote:
>> > On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote:
>> >> >>> On 01.02.17 at 13:02, wrote:
>> >> > +static int _fuzz_read_msr(
>> >> > +unsigned i
>>> On 02.02.17 at 18:43, wrote:
> On Wed, Feb 01, 2017 at 06:03:20AM -0700, Jan Beulich wrote:
>> >>> On 01.02.17 at 13:02, wrote:
>> > --- a/tools/tests/x86_emulator/Makefile
>> > +++ b/tools/tests/x86_emulator/Makefile
>> > @@ -45,7 +45,7 @@ x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h:
flight 105330 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105330/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
flight 105297 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105297/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 3 host-install(3) broken REGR. vs. 10525
flight 105319 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105319/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
flight 105295 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105295/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken in 105276 REGR. vs. 59254
test-amd64-amd64-xl
flight 105313 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105313/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
flight 105304 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105304/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
flight 105300 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105300/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
On Thu, Feb 02, 2017 at 03:12:52PM -0800, Stefano Stabellini wrote:
> On Thu, 2 Feb 2017, Edgar E. Iglesias wrote:
> > On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> > > Hi Edgar,
> > >
> > > On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> > > >On Tue, Jan 31, 2017 at 05:09:53PM +
On 02/02/2017 23:25, Stefano Stabellini wrote:
> On Thu, 2 Feb 2017, Julien Grall wrote:
>> Commit 146786b "efi: create efi_enabled()" introduced a variable
>> efi_flags stored in BSS and used to pass information between the stub
>> and Xen. However on ARM, BSS is zeroed after the stub has finished
On Thu, 2 Feb 2017, Julien Grall wrote:
> Commit 146786b "efi: create efi_enabled()" introduced a variable
> efi_flags stored in BSS and used to pass information between the stub
> and Xen. However on ARM, BSS is zeroed after the stub has finished to
> run and before Xen is started. This means that
On Thu, Feb 02, 2017 at 07:25:32PM +, Julien Grall wrote:
> Commit 146786b "efi: create efi_enabled()" introduced a variable
> efi_flags stored in BSS and used to pass information between the stub
> and Xen. However on ARM, BSS is zeroed after the stub has finished to
> run and before Xen is st
On Thu, 2 Feb 2017, Edgar E. Iglesias wrote:
> On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> > Hi Edgar,
> >
> > On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> > >On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
> > >>On 31/01/17 16:53, Edgar E. Iglesias wrote:
> >
On Thu, 2 Feb 2017, Julien Grall wrote:
> Hi Roger,
>
> On 01/02/17 10:55, Roger Pau Monné wrote:
> > On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 24/01/17 20:07, Stefano Stabellini wrote:
> > > > On Tue, 24 Jan 2017, Julien Grall wrote:
> > > > >
On Thu, 2 Feb 2017, Julien Grall wrote:
> There are quite a few usage of "lenght" instead of "length" in different
> part of the repo. Correct it once for all.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
> Cc: George Dunlap
> Cc: Dario
On Thu, 2 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 01/02/17 23:23, Stefano Stabellini wrote:
> > On Wed, 1 Feb 2017, Julien Grall wrote:
> > > On 31/01/2017 23:49, Stefano Stabellini wrote:
> > > > On Fri, 27 Jan 2017, Julien Grall wrote:
> > > > > On 03/01/17 23:29, Stefano Stabellini w
On Thu, Feb 02, 2017 at 04:46:14PM -0600, Doug Goldstein wrote:
> On 2/2/17 4:41 PM, Daniel Kiper wrote:
> > On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote:
> >> Build xen.gz with EFI code. We need this to support multiboot2
> >> protocol on EFI platforms.
> >>
> >> If we wish to load
On Thu, Feb 02, 2017 at 04:27:24PM -0600, Doug Goldstein wrote:
> On 2/2/17 4:01 PM, Daniel Kiper wrote:
> > Hi,
> >
> > I am sending fourteenth version of multiboot2 protocol support for
> > legacy BIOS and EFI platforms. This patch series release contains
> > fixes for all known/confirmed issues.
Since c/s eee5909e9d (x86/EFI: use less crude a way of generating the
build ID) builds have been broken when using GNU Make 4.1. This is
because there are no dependencies on buildid.o and as such GNU Make does
not build it. This adds a dependency so that it is built.
Note: This patch is different
On 2/2/17 4:41 PM, Daniel Kiper wrote:
> On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote:
>> Build xen.gz with EFI code. We need this to support multiboot2
>> protocol on EFI platforms.
>>
>> If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
>> it must contain "li
On Thu, Feb 02, 2017 at 11:01:14PM +0100, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper
> ---
> v14 - suggestions/fixes:
> - mark .init.data section as writable; by the w
On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote:
> Build xen.gz with EFI code. We need this to support multiboot2
> protocol on EFI platforms.
>
> If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
> it must contain "linear" (or "flat") representation of code and d
When the libxl driver is initialized, it creates a virDomainDef
object for dom0 and adds it to the list of domains. Total memory
for dom0 was being set from the max_memkb field of libxl_dominfo
struct retrieved from libxl, but this field can be set to
LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum mem
The libxl driver reports different values of maximum memory depending
on state of a domain. If inactive, maximum memory value is reported
correctly. When active, maximum memory is derived from max_pages value
returned by the XEN_SYSCTL_getdomaininfolist sysctl operation. But
max_pages can be change
Patch 1 fixes reporting of domain maximum memory for running domains.
When creating a virDomainDef object to represent dom0, max memory was
not set correctly, which is fixed by patch2.
Jim Fehlig (2):
libxl: fix reporting of maximum memory
libxl: fix dom0 maximum memory setting
src/libxl/lib
On 2/2/17 4:01 PM, Daniel Kiper wrote:
> Hi,
>
> I am sending fourteenth version of multiboot2 protocol support for
> legacy BIOS and EFI platforms. This patch series release contains
> fixes for all known/confirmed issues.
>
> The final goal is xen.efi binary file which could be loaded by EFI
>
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-b
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
Hi,
I am sending fourteenth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known/confirmed issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS pl
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
---
v14 - suggestions/fixes:
- mark .init.data section as writable; by the way we must change
similar definition in xen/arch/x86/boot/x86_64.S be
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file con
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
Reviewe
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e6f6ef1..24b4b23 100644
---
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory fro
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan
On Thu, 2 Feb 2017, Artem Mygaiev wrote:
> Hello Julien, Stefano
>
> [coverity-related question]
>
> On 27.01.17 20:11, Julien Grall wrote:
> > (CC Artem as ARM coverity admin)
> >> Coverity-ID: 1381855
> >> Coverity-ID: 1381853
> >
> > I am bit confused... somehow those numbers disappeared from
This run is configured for baseline tests only.
flight 68506 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 16 guest-start.2
flight 105294 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105294/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 3 host-install(3)broken REGR. vs. 1052
There are quite a few usage of "lenght" instead of "length" in different
part of the repo. Correct it once for all.
Signed-off-by: Julien Grall
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: George Dunlap
Cc: Dario Faggioli
Cc: Stefano Stabellini
---
tools/libxl/libxl_json.c | 4 ++--
xen/c
Commit 146786b "efi: create efi_enabled()" introduced a variable
efi_flags stored in BSS and used to pass information between the stub
and Xen. However on ARM, BSS is zeroed after the stub has finished to
run and before Xen is started. This means that the bits set in efi_flags
will be lost.
We wer
From: Paul Durrant
...not just IDE and SCSI.
This patch allows the Xen tool-stack to fully support of NVMe as an
emulated disk type. See [1] for the relevant tool-stack patch discussion.
[1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg01225.html
Signed-off-by: Paul Durrant
Review
From: Paul Durrant
The Xen HVM unplug protocol [1] specifies a mechanism to allow guests to
request unplug of 'aux' disks (which is stated to mean all IDE disks,
except the primary master). This patch adds support for that unplug request.
NOTE: The semantics of what happens if unplug of all disk
From: Juergen Gross
The error exits of xen_pv_find_xendev() free the new xen-device via
g_free() which is wrong.
As the xen-device has been initialized as qdev it must be removed
via qdev_unplug().
This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6
("xen: create qdev for each bac
emu-dm.git tags/xen-20170202
for you to fetch changes up to e9dcbc86d614018923e26e31319b0a54c9e5abac:
xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()
(2017-02-02 10:23:53 -0800)
Xen
From: Paul Durrant
The current code is poorly structured and potentially leads to multiple
config space reads when one is sufficient. Also the UNPLUG_ALL_IDE_DISKS
flag is mis-named since it also results in SCSI disks being unplugged.
This patch renames the flag and re-structures the code to be
Folks, (people who have current projects are CC'ed)
I just created https://wiki.xenproject.org/wiki/2017-Summer-Internships and
https://wiki.xenproject.org/wiki/Category:Internships as we are planning to
apply as mentoring organisation for GSoC 2017 again.
To be successful, we need to bring our
Apologies: typo in CC list
Regards
Lars
> On 2 Feb 2017, at 18:36, Lars Kurth wrote:
>
> Folks, (people who have current projects are CC'ed)
>
> I just created https://wiki.xenproject.org/wiki/2017-Summer-Internships and
> https://wiki.xenproject.org/wiki/Category:Internships as we are plannin
From: Anthony PERARD
Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a428cb2..baea7c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -323,7 +323,7 @@ Guest CPU Cores (X
On Thu, 2 Feb 2017, Juergen Gross wrote:
> On 01/02/17 21:20, Peter Maydell wrote:
> > On 1 February 2017 at 19:37, Stefano Stabellini
> > wrote:
> >> Hi Peter,
> >>
> >> do you think this is acceptable?
> >
> > The set of operations here is basically what I suggested
> > in review of v1, so I t
On 02/02/2017 04:42 AM, Wei Liu wrote:
I saw this mail but didn't realise it required my input, sorry.
I suppose it didn't and I was shamelessly fishing for a review - so you have my
apologies :-). But the patch does fix an annoying, easily encountered bug which
I'm eager to see resolved in t
Information we currently print for idle pCPUs is
rather useless. Credit2 already stopped showing that,
do the same for Credit and RTDS.
Also, define a new CPU status dump hook, which is
not defined by those schedulers which already dump
such info in other ways (e.g., Credit2, which does
that while
flight 105293 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105293/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Thu, 2 Feb 2017, Jan Beulich wrote:
> The need for 8844ed299a ("x86/dmop: Fix compat_dm_op() ABI") has made
> clear that its presence is actively dangerous. At the hypercall entry
> points XEN_GUEST_HANDLE_PARAM() should be used anyway (regardless of
> whether these are native or compat entry po
Information we currently print for idle pCPUs is
rather useless. Credit2 already stopped showing that,
do the same for Credit and RTDS.
Also, define a new CPU status dump hook, which is
not defined by those schedulers which already dump
such info in other ways (e.g., Credit2, which does
that while
On 02/02/2017 11:40 AM, Roger Pau Monné wrote:
> On Thu, Feb 02, 2017 at 11:30:19AM -0500, Boris Ostrovsky wrote:
>> On 02/02/2017 10:35 AM, Roger Pau Monné wrote:
>>> On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote:
Make sure they don't use these devices since they are not emu
On Wed, Feb 01, 2017 at 06:03:20AM -0700, Jan Beulich wrote:
> >>> On 01.02.17 at 13:02, wrote:
> > --- a/tools/tests/x86_emulator/Makefile
> > +++ b/tools/tests/x86_emulator/Makefile
> > @@ -45,7 +45,7 @@ x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h:
> >
> > HOSTCFLAGS += $(CFLAGS_xenin
On Thu, Feb 02, 2017 at 10:01:46AM -0700, Jan Beulich wrote:
> >>> On 02.02.17 at 17:50, wrote:
> > On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote:
> >> >>> On 01.02.17 at 13:02, wrote:
> >> > +static int fuzz_read_segment(
> >> > +enum x86_segment seg,
> >> > +struct segment
On Thu, Feb 02, 2017 at 11:30:19AM -0500, Boris Ostrovsky wrote:
> On 02/02/2017 10:35 AM, Roger Pau Monné wrote:
> > On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote:
> >> Make sure they don't use these devices since they are not emulated
> >> for unprivileged PVH guest.
> > This de
>>> On 02.02.17 at 17:50, wrote:
> On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote:
>> >>> On 01.02.17 at 13:02, wrote:
>> > +static int fuzz_read_segment(
>> > +enum x86_segment seg,
>> > +struct segment_register *reg,
>> > +struct x86_emulate_ctxt *ctxt)
>> > +{
>> > +
On Wed, 2017-02-01 at 14:59 +, George Dunlap wrote:
> On 26/01/17 16:52, Dario Faggioli wrote:
> >
> > Scheduling information debug dump for Credit2 is hard
> > to read as it contains the same information repeated
> > multiple time in different ways.
> >
> > [..]
> >
> > Signed-off-by: Dario
On Wed, Feb 01, 2017 at 06:05:23AM -0700, Jan Beulich wrote:
> >>> On 01.02.17 at 13:02, wrote:
> > --- a/xen/include/asm-x86/processor.h
> > +++ b/xen/include/asm-x86/processor.h
> > @@ -16,6 +16,8 @@
> > #include
> > #endif
> >
> > +#include "x86-defns.h"
>
> This should be .
Right. I wil
flight 105276 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken REGR. vs. 59254
test-armhf-armhf-xl
On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote:
> >>> On 01.02.17 at 13:02, wrote:
> > @@ -16,26 +17,78 @@
> >
> > #include "x86_emulate.h"
> >
> > -static unsigned char data[4096];
> > +#define MSR_INDEX_MAX 16
> > +
> > +#define SEG_NUM x86_seg_none
> > +
> > +struct input_stru
flight 105279 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105279/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105016
test-amd64-amd64-xl-qemuu-
On 02/02/2017 10:35 AM, Roger Pau Monné wrote:
> On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote:
>> Make sure they don't use these devices since they are not emulated
>> for unprivileged PVH guest.
> This description seems weird for what it's actually done. AFAICT you are not
> rea
Wei Liu writes ("Re: [PATCH 2/2] xl: disable events earlier for shutdown
event"):
> No, handling NULL is not enough. It could well be possible that diskws
> is not NULL but then num_disks grows, thus making evdisable_disk_ejects
> access out of bound.
The additional diskws entries could be zeroed
On Thu, Feb 02, 2017 at 03:46:36PM +, Wei Liu wrote:
> Otherwise it is leaked. Found by code inspection.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Jackson
> Cc: Fatih Acar
>
> Backport candidate.
> ---
> tools/libxl/xl_cmdimpl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/t
On Thu, Feb 02, 2017 at 04:05:08PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH 2/2] xl: disable events earlier for shutdown
> event"):
> > On Thu, Feb 02, 2017 at 03:52:41PM +, Ian Jackson wrote:
> > > But I think I don't really understand what the original bug is.
> >
> > The ori
>>> On 02.02.17 at 16:41, wrote:
> On 02/02/17 15:25, Jan Beulich wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -329,13 +329,16 @@ unsigned long __init alloc_boot_pages(
>> unsigned long nr_pfns, unsigned long pfn_align)
>> {
>> unsigned long pg, _e;
>>
Wei Liu writes ("Re: [PATCH 2/2] xl: disable events earlier for shutdown
event"):
> On Thu, Feb 02, 2017 at 03:52:41PM +, Ian Jackson wrote:
> > But I think I don't really understand what the original bug is.
>
> The original bug is that:
Ah.
> 1. boot a guest with no disks, so diskws is NU
Wei Liu writes ("Re: [PATCH] xl: remove stale comment"):
> On Thu, Feb 02, 2017 at 03:56:03PM +, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH] xl: remove stale comment"):
> > > case LIBXL_EVENT_TYPE_DISK_EJECT:
> > > -/* XXX what is this for? */
> > > libxl_c
On Thu, Feb 02, 2017 at 03:56:03PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] xl: remove stale comment"):
> > Obvious the DISK_EJECT event is for ejecting removable media.
>
> The question is...
>
> > case LIBXL_EVENT_TYPE_DISK_EJECT:
> > -/* XXX what is this for? *
Wei Liu writes ("[PATCH] xl: remove stale comment"):
> Obvious the DISK_EJECT event is for ejecting removable media.
The question is...
> case LIBXL_EVENT_TYPE_DISK_EJECT:
> -/* XXX what is this for? */
> libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk,
On Thu, Feb 02, 2017 at 03:52:41PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 2/2] xl: disable events earlier for shutdown event"):
> > We need to disable event machinery when the guest shuts down. It
> > doesn't really matter where we disable it as long as it is within the
> > branch for
Obvious the DISK_EJECT event is for ejecting removable media.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Ian, feel free to tell me that I'm wrong...
---
tools/libxl/xl_cmdimpl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 196b8a6
Wei Liu writes ("[PATCH 2/2] xl: disable events earlier for shutdown event"):
> We need to disable event machinery when the guest shuts down. It
> doesn't really matter where we disable it as long as it is within the
> branch for shutdown event.
I don't think this is necessary. My intent was tha
On 02/02/2017 09:54 AM, Ross Lagerwall wrote:
> On 02/01/2017 06:54 PM, Boris Ostrovsky wrote:
>> On 02/01/2017 10:50 AM, Ross Lagerwall wrote:
>>> Improve error handling during initialization. This fixes a crash when
>>> running out of grant refs when creating many queues across many
>>> netdevs.
Otherwise it is leaked. Found by code inspection.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Fatih Acar
Backport candidate.
---
tools/libxl/xl_cmdimpl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7e8a8ae5c4..9bf10dfcb2 100
Wei Liu (2):
xl: free event in DOMAIN_RESTART_RENAME error path
xl: disable events earlier for shutdown event
tools/libxl/xl_cmdimpl.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
2.11.0
___
Xen-devel mailing list
Xen-devel@
We need to disable event machinery when the guest shuts down. It
doesn't really matter where we disable it as long as it is within the
branch for shutdown event.
Move the code snippet before handle_domain_death, so that d_config is
not yet updated and we have the correct ->num_disks. And the free
On 02/02/17 15:25, Jan Beulich wrote:
> ... to make alloc_boot_pages() fail for late callers. Don't rely on
> reaching the BOOT_BUG_ON(1) near the end of that function though, but
> instead make this situation easier to distinguish from actual
> allocation failures by adding an explicit check.
>
>
On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> Or maybe we could avoid mapping the doorbell in the guest and let Xen
> receive an SMMU abort. When receiving the SMMU abort, Xen could sanitize the
> value and write into the real MSI doorbell. Not sure if it would works
> thought.
A
On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote:
> Make sure they don't use these devices since they are not emulated
> for unprivileged PVH guest.
This description seems weird for what it's actually done. AFAICT you are not
really preventing the guest from using the PIC or the IO
On Thu, Feb 2, 2017 at 1:30 PM, Vincent Legout wrote:
> On Thu, Feb 02, 2017 at 12:05:09PM +, Andrew Cooper wrote :
>> On 02/02/17 07:58, Vincent Legout wrote:
>> > Hello,
>> >
>> > We had some issues after live migrating several domU from xen 4.1 to xen
>> > 4.8. We migrated around 200 domU a
flight 105289 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 6 xen-boot fail REGR. vs. 105218
test-amd64-a
>>> On 27.01.17 at 20:48, wrote:
> At 09:40 -0700 on 27 Jan (1485510008), Jan Beulich wrote:
>> - vmx_set_segment_register() should initialize the TSS every
>> time (including setting the I/O bitmap address to no lower
>> than 32)
>
> Probably to no lower than 136, to avoid having the bits of
On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> Hi Edgar,
>
> On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> >On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
> >>On 31/01/17 16:53, Edgar E. Iglesias wrote:
> >>>On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall w
On 02/02/2017 09:52 AM, Jan Beulich wrote:
On 02.02.17 at 15:09, wrote:
>> On 02/02/17 13:56, osstest service owner wrote:
>>> flight 105283 xen-unstable-smoke real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/105283/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed
... to make alloc_boot_pages() fail for late callers. Don't rely on
reaching the BOOT_BUG_ON(1) near the end of that function though, but
instead make this situation easier to distinguish from actual
allocation failures by adding an explicit check.
While there, make the iteration variable unsigned
On 26/01/17 20:41, Boris Ostrovsky wrote:
> Make sure they don't use these devices since they are not emulated
> for unprivileged PVH guest.
>
> Also don't initialize hypercall page for them in init_hvm_pv_info()
> since this has already been done.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by
>>> On 02.02.17 at 16:08, wrote:
> Adjust/manage the return values of register_one_rmrr() such that new
> callers log errors for non-debug builds too, while not affecting the
> behavior of the original callers.
>
> Signed-off-by: Venu Busireddy
Reviewed-by: Jan Beulich
_
Adjust/manage the return values of register_one_rmrr() such that new
callers log errors for non-debug builds too, while not affecting the
behavior of the original callers.
Signed-off-by: Venu Busireddy
---
xen/drivers/passthrough/vtd/dmar.c | 11 +++
1 file changed, 11 insertions(+)
v2
On 02/01/2017 06:54 PM, Boris Ostrovsky wrote:
On 02/01/2017 10:50 AM, Ross Lagerwall wrote:
Improve error handling during initialization. This fixes a crash when
running out of grant refs when creating many queues across many netdevs.
* Delay timer creation so that if initializing a queue fail
>>> On 02.02.17 at 15:09, wrote:
> On 02/02/17 13:56, osstest service owner wrote:
>> flight 105283 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/105283/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could n
On 02/02/17 13:56, osstest service owner wrote:
> flight 105283 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105283/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemuu-debi
1 - 100 of 147 matches
Mail list logo
