Hello,
We had some issues after live migrating several domU from xen 4.1 to xen
4.8. We migrated around 200 domU and 5 crashed, from a few hours up to
several days after the migration. All the domU had more than 1 year of
uptime, and for example one crashed several days after the migration
during
flight 105236 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105236/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254
test-amd64-i386-xl-
flight 105262 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105262/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104989
test-armhf-armhf-libvirt 13
Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.
Reason seems to be a missing adaption similar to that done in
commit 7453c549f5f648 ("
flight 68505 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68505/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-wheezy-netboot-pvgrub 9 debian-di-install fail blocked in
68487
Tests whi
flight 105258 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105258/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail pass in 105224
Regressions which are regarded a
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 think it is the right thing.
> OTOH this is a bit of an odd
On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> disposable private objects") introduced a regression for the kernel
> running as Xen dom0: when switching to graphics mode a GPU HANG
> occurred.
>
> Reason seem
On Thu, Feb 02, 2017 at 11:48:21AM +0100, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> > Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> > disposable private objects") introduced a regression for the kernel
> > running as Xen dom0:
>>> On 01.02.17 at 10:44, wrote:
On 31.01.17 at 18:00, wrote:
>> That brings up this question. Do we want to disable VT-d if the PCIe
>> device specified via ACPI cannot be detected? We do so if the address
>> range is incorrectly specified. If the answer is yes, then returning
>> -EINVAL ma
>>> On 01.02.17 at 18:51, wrote:
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -840,13 +841,13 @@ static int __init acpi_parse_dmar(struct
> acpi_table_header *table)
> entry_header->type);
> break;
> }
> -
On Thu, Feb 2, 2017 at 7:58 AM, 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 and 5 crashed, from a few hours up to
> several days after the migration. All the domU had more than 1 year of
> uptime, an
>>> On 01.02.17 at 19:21, wrote:
> On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote:
>> Hi Dario,
>>
>> On 25/01/17 16:00, Dario Faggioli wrote:
>> > On Wed, 2017-01-25 at 12:38 +, Julien Grall wrote:
>> > > On 25/01/17 11:10, Dario Faggioli wrote:
>> > And a good one. I may be wr
On Mon, Jan 30, 2017 at 03:31:49PM +0100, Fatih Acar wrote:
> If we have no disk attached at startup, diskws is left unallocated
> but `d_config.num_disks` may change if we attach a disk later.
> When a domain is rebooted `evdisable_disk_ejects` is called
> this will later result in a segfault if n
On Mon, Jan 30, 2017 at 03:33:18PM +0100, Fatih Acar wrote:
> libxl_domain_build_info_dispose is not resetting the type field to
> LIBXL_DOMAIN_TYPE_INVALID.
> Instead, it is memseting the struct to 0 thus when
> libxl_domain_build_info_init_type is called
> after a dispose on the same struct, an
This run is configured for baseline tests only.
flight 68504 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/deb
On 01/02/17 10:59, Jan Beulich wrote:
> The initial operation done on these paths may raise an exception (for
> ->read_io() that's possible only on the PV path, when the I/O port
> access check has been deferred). We have to suppress put_rep_prefix()
> updating rCX in that case. From an abstract pe
I saw this mail but didn't realise it required my input, sorry.
On Wed, Feb 01, 2017 at 04:00:54PM -0700, Jim Fehlig wrote:
> Jim Fehlig wrote:
> > xen.git commit 57f8b13c changed several of the libxl memory
> > get/set functions to take 64 bit parameters. The libvirt
> > libxl driver still uses u
On 05/01/17 14:42, Jan Beulich wrote:
On 20.12.16 at 13:35, wrote:
>> Once we have ever had cause to use time_calibration_tsc_rendezvous,
>> there is no situation where it is safe to switch back to
>> time_calibration_std_rendezvous, as the choice to use
>> time_calibration_tsc_rendezvous mea
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 points), and passing around
handles internally sh
On Thu, Feb 02, 2017 at 04:45:37AM -0700, 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 nat
On Thu, Feb 02, 2017 at 04:22:53AM -0700, Jan Beulich wrote:
> >>> On 01.02.17 at 19:21, wrote:
> > On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote:
> >> Hi Dario,
> >>
> >> On 25/01/17 16:00, Dario Faggioli wrote:
> >> > On Wed, 2017-01-25 at 12:38 +, Julien Grall wrote:
> >> >
On 02/02/2017 12:25, Wei Liu wrote:
>
> You didn't check if diskws_new is NULL.
>
> Actually you can just use xrealloc here.
>
You're right, using xrealloc is much better here.
>
> It seems that you've used "xl config-update" to update the domain
> configuration. Is this correct?
>
> But act
On Thu, 2017-02-02 at 04:22 -0700, Jan Beulich wrote:
> On 01.02.17 at 19:21, wrote:
> > On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote:
> > > Yeah, even the tiny RCU code is quite complex :/. I've looked at
> > > our RCUcode and noticed there is a link in the header to [1].
> >
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 and 5 crashed, from a few hours up to
> several days after the migration. All the domU had more than 1 year of
> uptime, and for example
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 wrote:
So we have to worry about SPIs and LPIs (thought they are not
On 02/02/2017 09:47, Juergen Gross wrote:
Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.
Reason seems to be a missing adaption sim
Hi,
On 02/02/17 11:53, Wei Liu wrote:
On Thu, Feb 02, 2017 at 04:22:53AM -0700, Jan Beulich wrote:
On 01.02.17 at 19:21, wrote:
On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote:
Hi Dario,
On 25/01/17 16:00, Dario Faggioli wrote:
On Wed, 2017-01-25 at 12:38 +, Julien Grall w
This permits to have control over the devid attribute when attaching new nics.
It may become useful if one has its own nic indexing somewhere else than
xl/xenstore.
Signed-off-by: Fatih Acar
Signed-off-by: Nikita Kozlov
Signed-off-by: Vincent Legout
Signed-off-by: Baptiste Daroussin
---
docs
>>> 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_struct {
> +unsigned long cr[5];
> +uint64_t msr[MSR_INDEX_MAX];
> +struct
On Thu, Feb 02, 2017 at 12:11:29PM +, Tvrtko Ursulin wrote:
>
> On 02/02/2017 09:47, Juergen Gross wrote:
> >Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> >disposable private objects") introduced a regression for the kernel
> >running as Xen dom0: when switching to gr
On Wed, Feb 01, 2017 at 05:44:55PM +, Roger Pau Monne wrote:
[...]
> diff --git a/tools/libs/gnttab/private.h b/tools/libs/gnttab/private.h
> index d6c5594..1416194 100644
> --- a/tools/libs/gnttab/private.h
> +++ b/tools/libs/gnttab/private.h
> @@ -4,6 +4,16 @@
> #include
> #include
>
>
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:
whilst for Device Tree the segment number is not available.
So Xen needs to rel
On Thu, Feb 02, 2017 at 11:26:16AM +, Wei Liu wrote:
> On Mon, Jan 30, 2017 at 03:33:18PM +0100, Fatih Acar wrote:
> > libxl_domain_build_info_dispose is not resetting the type field to
> > LIBXL_DOMAIN_TYPE_INVALID.
> > Instead, it is memseting the struct to 0 thus when
> > libxl_domain_buil
>>> On 31.01.17 at 12:20, wrote:
> --- a/tools/tests/x86_emulator/x86_emulate.h
> +++ b/tools/tests/x86_emulator/x86_emulate.h
> @@ -46,6 +46,12 @@
> #define MMAP_SZ 16384
> bool emul_test_make_stack_executable(void);
>
> +#ifdef __GCC_ASM_FLAG_OUTPUTS__
> +# define ASM_FLAG_OUT(yes, no) yes
>
On Thu, Feb 02, 2017 at 01:20:49PM +0100, Fatih Acar wrote:
> This permits to have control over the devid attribute when attaching new nics.
> It may become useful if one has its own nic indexing somewhere else than
> xl/xenstore.
>
> Signed-off-by: Fatih Acar
> Signed-off-by: Nikita Kozlov
> S
>>> On 31.01.17 at 12:20, wrote:
> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
> @@ -401,32 +401,27 @@ static always_inline void __vmwrite(unsigned long
> field, unsigned long value)
> );
> }
>
> -static inline bool_t __vmread_safe(unsigned long f
>>> On 31.01.17 at 12:20, wrote:
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -264,7 +264,7 @@ u64 get_vvmcs_real(const struct vcpu *v, u32 encoding)
> return virtual_vmcs_vmread(v, encoding);
> }
>
> -void set_vvmcs_virtual(void *vvmcs, u32 vmcs_encoding, u
On Thu, 2017-02-02 at 12:18 +, Julien Grall wrote:
> Dario, are you going to look into the issue? Or shall I try to write
> a
> patch for it?
>
I'd be up for looking into this. BUT, I'm travelling this weekend, and
am probably going to be busy next week (sorry).
So, I expect to be able to do
On Thu, Feb 02, 2017 at 11:22:02AM +, George Dunlap wrote :
> On Thu, Feb 2, 2017 at 7:58 AM, 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 and 5 crashed, from a few hours up to
> > seve
On 02/02/17 12:52, Jan Beulich wrote:
On 31.01.17 at 12:20, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -264,7 +264,7 @@ u64 get_vvmcs_real(const struct vcpu *v, u32 encoding)
>> return virtual_vmcs_vmread(v, encoding);
>> }
>>
>> -void set_v
Hi Dario,
On 02/02/17 12:51, Dario Faggioli wrote:
On Thu, 2017-02-02 at 12:18 +, Julien Grall wrote:
Dario, are you going to look into the issue? Or shall I try to write
a
patch for it?
I'd be up for looking into this. BUT, I'm travelling this weekend, and
am probably going to be busy ne
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 and 5 crashed, from a few hours up to
> > several days after th
On Thu, 2017-02-02 at 13:26 +, Julien Grall wrote:
> On 02/02/17 12:51, Dario Faggioli wrote:
> > So, I expect to be able to do something useful only, let's stay,
> > from
> > Mon 13th. If that's ok, do sign me up. If you're more in a hurry,
> > feel
> > free to beat me. :-)
>
> I have plenty
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-debianhvm-i386 6 xen-boot fail REGR. vs. 105218
test-amd64-a
On 02/02/17 13:30, 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 and 5 crashed, from
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 the main Coverity
> page. Which means Coverity think they ha
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
>>> 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/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
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.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
_
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
... 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 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
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 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
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 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
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 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 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.
>
>
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
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 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.
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
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
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: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 ("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
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
>>> 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;
>>
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 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
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 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
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 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 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 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
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 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 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 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 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 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
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 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
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
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 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
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
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
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
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
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
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
1 - 100 of 147 matches
Mail list logo
