>>> On 10.05.19 at 03:28, wrote:
> Hi all,
>
> following a discussion with committers about Guest testing in OSSTEST, it
> surfaced that we have not updated what distros we test in OSSTEST for a very
> long time. All agreed that we should regularly review what we test against:
> maybe at the b
>>> On 09.05.19 at 21:48, wrote:
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -40,6 +40,11 @@ static int __init parse_font_height(const char *s)
> }
> custom_param("font", parse_font_height);
>
> +static inline paddr_t lfb_base(void)
> +{
> +return (paddr_t)(vlfb_
>>> On 10.05.19 at 00:02, wrote:
> I think the most important thing to do first is to understand how MOV-DR
> events are intended to be used, and what kind of behaviour we want,
> given that the two can't be shared in practice.
I think they can be shared, but at a significant price: Since DRn
spe
flight 135873 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135873/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
test-arm64-arm64-ex
>>> On 08.05.19 at 16:36, wrote:
> On 06/05/2019 12:01, Jan Beulich wrote:
> On 06.05.19 at 11:23, wrote:
>>> And that was mentioned in the cover letter: cpu hotplug is not yet
>>> handled (hence the RFC status of the series).
>>>
>>> When cpu hotplug is being added it might be appropriate to
On 10/05/2019 10:53, Jan Beulich wrote:
On 08.05.19 at 16:36, wrote:
>> On 06/05/2019 12:01, Jan Beulich wrote:
>> On 06.05.19 at 11:23, wrote:
And that was mentioned in the cover letter: cpu hotplug is not yet
handled (hence the RFC status of the series).
When cpu ho
flight 135883 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
build-amd64-pre
If a domU has a qemu-xen instance attached, it is required to call qemus
"xen-save-devices-state" method. Without it, the receiving side of a PV or
PVH migration may be unable to lock the image:
xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
error: Failed to get "write
On Fri, 2019-05-10 at 11:00 +0200, Juergen Gross wrote:
> On 10/05/2019 10:53, Jan Beulich wrote:
> > > > > On 08.05.19 at 16:36, wrote:
> > >
> > > With sched-gran=core or sched-gran=socket offlining a single cpu
> > > results
> > > in moving the complete core or socket to cpupool_free_cpus and
On Thu, 2019-05-09 at 19:00 +0100, Andrew Cooper wrote:
> >
> On 09/05/2019 18:46, Tamas K Lengyel wrote:
> >
>
> I have some plans to replace it with something far more usable, as
> part
> of tying together some XTF-based VMI testing, but none of that is
> remotely ready yet.
Hi Andrew,
Did yo
On 10/05/2019 11:52, Petre Ovidiu PIRCALABU wrote:
> On Thu, 2019-05-09 at 19:00 +0100, Andrew Cooper wrote:
>> On 09/05/2019 18:46, Tamas K Lengyel wrote:
>> I have some plans to replace it with something far more usable, as
>> part
>> of tying together some XTF-based VMI testing, but none of that
>>> On 10.05.19 at 11:00, wrote:
> On 10/05/2019 10:53, Jan Beulich wrote:
> On 08.05.19 at 16:36, wrote:
>>> On 06/05/2019 12:01, Jan Beulich wrote:
>>> On 06.05.19 at 11:23, wrote:
> And that was mentioned in the cover letter: cpu hotplug is not yet
> handled (hence the RFC sta
On 10/05/2019 12:29, Dario Faggioli wrote:
> On Fri, 2019-05-10 at 11:00 +0200, Juergen Gross wrote:
>> On 10/05/2019 10:53, Jan Beulich wrote:
>> On 08.05.19 at 16:36, wrote:
With sched-gran=core or sched-gran=socket offlining a single cpu
results
in moving the complete co
>>> On 07.05.19 at 17:14, wrote:
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -474,7 +474,8 @@ static inline void trace_resync(int event, mfn_t gmfn)
> if ( tb_init_done )
> {
> /* Convert gmfn to gfn */
> -unsigned long gfn = mfn_
>>> On 07.05.19 at 17:14, wrote:
> mfn_to_gfn and mfn_to_gmfn are doing exactly the same except the former
> is using mfn_t.
... and gfn_t (return type) as of patch 3.
> Furthermore, the naming of the former is more consistent with the
> current naming scheme (GFN/MFN). So use replace mfn_to_gmf
>>> On 07.05.19 at 17:14, wrote:
> This patch introduces a config option HAS_M2P to tell whether an
> architecture implements the M2P.
> - iommu_hwdom_init: For now, we require the M2P support when the IOMMU
> is not sharing the P2M.
> - memory_exchange: The hypercall is marked as not
> On 10 May 2019, at 01:48, Jan Beulich wrote:
>>
>> With regards to Windows testing we have some restrictions. We have tried
>> several times to buy additional test licenses, but this never went anywhere
>> (some of the VM licenses are not available for our environment, unless you
>> bulk b
>>> On 07.05.19 at 17:14, wrote:
> +static inline void set_gpfn_from_mfn(unsigned long mfn, unsigned long pfn)
> +{
> +struct domain *d = page_get_owner(mfn_to_page(_mfn(mfn)));
> +unsigned long entry = (d && (d == dom_cow)) ? SHARED_M2P_ENTRY : pfn;
The && here looks, ehm, funny, but I g
>>> On 07.05.19 at 17:14, wrote:
> @@ -2177,8 +2177,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e,
> l1_pgentry_t nl1e,
> }
> else if ( pv_l1tf_check_l1e(pt_dom, nl1e) )
> return -ERESTART;
> -else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
> -
flight 135891 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135891/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 15 leak-check/check fail REGR. vs. 133923
test-amd64-i386-qemu
On 10/05/2019 12:35, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -474,7 +474,8 @@ static inline void trace_resync(int event, mfn_t gmfn)
if ( tb_init_done )
{
/* Convert gmfn to gfn */
-
Hi Jan,
On 10/05/2019 13:15, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
mfn_to_gfn and mfn_to_gmfn are doing exactly the same except the former
is using mfn_t.
... and gfn_t (return type) as of patch 3.
Furthermore, the naming of the former is more consistent with the
current naming s
Hi,
On 10/05/2019 13:31, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
This patch introduces a config option HAS_M2P to tell whether an
architecture implements the M2P.
- iommu_hwdom_init: For now, we require the M2P support when the IOMMU
is not sharing the P2M.
- memory_exch
>>> On 10.05.19 at 15:02, wrote:
>
> On 10/05/2019 12:35, Jan Beulich wrote:
> On 07.05.19 at 17:14, wrote:
>>> --- a/xen/arch/x86/mm/shadow/common.c
>>> +++ b/xen/arch/x86/mm/shadow/common.c
>>> @@ -474,7 +474,8 @@ static inline void trace_resync(int event, mfn_t gmfn)
>>> if ( tb_in
>>> On 07.05.19 at 17:14, wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -391,11 +391,12 @@ static inline void mem_sharing_gfn_destroy(struct
> page_info *page,
> xfree(gfn_info);
> }
>
> -static struct page_info* mem_sharing_lookup(unsigned long m
On 10/05/2019 14:24, Jan Beulich wrote:
On 10.05.19 at 15:02, wrote:
On 10/05/2019 12:35, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -474,7 +474,8 @@ static inline void trace_resync(int event, mfn_t gmfn
On 10/05/2019 14:21, Jan Beulich wrote:
>
>> @@ -2795,54 +2795,54 @@ void audit_p2m(struct domain *d,
>> spin_lock(&d->page_alloc_lock);
>> page_list_for_each ( page, &d->page_list )
>> {
>> -mfn = mfn_x(page_to_mfn(page));
>> +mfn = page_to_mfn(page);
>>
>> -
>>> On 07.05.19 at 17:14, wrote:
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -658,4 +658,18 @@ static inline void share_xen_page_with_privileged_guests(
> share_xen_page_with_guest(page, dom_xen, flags);
> }
>
> +/*
> + * Dummy implementation of M2P-related helpers for c
On 10/05/2019 14:28, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -658,4 +658,18 @@ static inline void share_xen_page_with_privileged_guests(
share_xen_page_with_guest(page, dom_xen, flags);
}
+/*
+ * Dummy implementation
>>> On 10.05.19 at 15:27, wrote:
> On 10/05/2019 13:43, Jan Beulich wrote:
> On 07.05.19 at 17:14, wrote:
>>> +static inline void set_gpfn_from_mfn(unsigned long mfn, unsigned long pfn)
>>> +{
>>> +struct domain *d = page_get_owner(mfn_to_page(_mfn(mfn)));
>>> +unsigned long entry = (
On 10/05/2019 14:21, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -391,11 +391,12 @@ static inline void mem_sharing_gfn_destroy(struct
page_info *page,
xfree(gfn_info);
}
-static struct page_info* mem_sh
>>> On 10.05.19 at 15:29, wrote:
> On 10/05/2019 14:28, Jan Beulich wrote:
> On 07.05.19 at 17:14, wrote:
>>> --- a/xen/include/xen/mm.h
>>> +++ b/xen/include/xen/mm.h
>>> @@ -658,4 +658,18 @@ static inline void
>>> share_xen_page_with_privileged_guests(
>>> share_xen_page_with_guest(p
Hi,
On 10/05/2019 13:43, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
+static inline void set_gpfn_from_mfn(unsigned long mfn, unsigned long pfn)
+{
+struct domain *d = page_get_owner(mfn_to_page(_mfn(mfn)));
+unsigned long entry = (d && (d == dom_cow)) ? SHARED_M2P_ENTRY : pfn;
T
On 10/05/2019 13:54, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
@@ -2177,8 +2177,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t
nl1e,
}
else if ( pv_l1tf_check_l1e(pt_dom, nl1e) )
return -ERESTART;
-else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e
>>> On 10.05.19 at 15:22, wrote:
> On 10/05/2019 13:31, Jan Beulich wrote:
> On 07.05.19 at 17:14, wrote:
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -205,7 +205,7 @@ void getdomaininfo(struct domain *d, struct
>>> xen_domctl_getdomaininfo *info)
>>> info->outstan
On 10/05/2019 14:37, Jan Beulich wrote:
On 10.05.19 at 15:29, wrote:
On 10/05/2019 14:28, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -658,4 +658,18 @@ static inline void share_xen_page_with_privileged_guests(
share_xen_pa
Hi Jan,
On 10/05/2019 14:32, Jan Beulich wrote:
On 10.05.19 at 15:22, wrote:
On 10/05/2019 13:31, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -205,7 +205,7 @@ void getdomaininfo(struct domain *d, struct
xen_domctl_getdomaininfo *inf
>>> On 10.05.19 at 15:34, wrote:
> On 10/05/2019 14:21, Jan Beulich wrote:
> On 07.05.19 at 17:14, wrote:
>>> @@ -1030,19 +1031,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
>>> /* check for 1GB super page */
>>> if ( l3e_get_flags(l3e[i3]) & _PAGE_PS
On 10/05/2019 14:35, Jan Beulich wrote:
On 10.05.19 at 15:27, wrote:
On 10/05/2019 13:43, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
+static inline void set_gpfn_from_mfn(unsigned long mfn, unsigned long pfn)
+{
+struct domain *d = page_get_owner(mfn_to_page(_mfn(mfn)));
+unsign
>>> On 10.05.19 at 15:41, wrote:
> On 10/05/2019 14:32, Jan Beulich wrote:
> On 10.05.19 at 15:22, wrote:
>>> On 10/05/2019 13:31, Jan Beulich wrote:
>>> On 07.05.19 at 17:14, wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -205,7 +205,7 @@ void getdomaini
On 10/05/2019 14:41, Jan Beulich wrote:
On 10.05.19 at 15:34, wrote:
On 10/05/2019 14:21, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
@@ -1030,19 +1031,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
@@ -2795,54 +2795,54 @@ void audit_p2m(struct domain *d,
spin_lock(&d->page
>>> On 10.05.19 at 15:41, wrote:
> On 10/05/2019 14:35, Jan Beulich wrote:
> On 10.05.19 at 15:27, wrote:
>>> On 10/05/2019 13:43, Jan Beulich wrote:
>>> On 07.05.19 at 17:14, wrote:
> +static inline void set_gpfn_from_mfn(unsigned long mfn, unsigned long
> pfn)
> +{
> +
Am Fri, 10 May 2019 12:04:16 +0200
schrieb Olaf Hering :
> v3 not runtime tested
The initialization for device_model_stubdomain must be moved to the new
function.
Olaf
pgphrT_DcBomp.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel maili
>>> On 10.05.19 at 15:46, wrote:
> On 10/05/2019 14:41, Jan Beulich wrote:
> On 10.05.19 at 15:34, wrote:
>>> On 10/05/2019 14:21, Jan Beulich wrote:
>>> On 07.05.19 at 17:14, wrote:
> @@ -1030,19 +1031,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
> @@ -2795,54 +2795,54 @@
Hi,
On 10/05/2019 14:48, Jan Beulich wrote:
On 10.05.19 at 15:41, wrote:
On 10/05/2019 14:35, Jan Beulich wrote:
On 10.05.19 at 15:27, wrote:
On 10/05/2019 13:43, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
+static inline void set_gpfn_from_mfn(unsigned long mfn, unsigned long pfn)
+
On 10/05/2019 15:02, Jan Beulich wrote:
On 10.05.19 at 15:46, wrote:
>> On 10/05/2019 14:41, Jan Beulich wrote:
>> On 10.05.19 at 15:34, wrote:
On 10/05/2019 14:21, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
>> @@ -1030,19 +1031,19 @@ long p2m_pt_audit_p2m(struct
Hi Jan,
On 10/05/2019 14:45, Jan Beulich wrote:
On 10.05.19 at 15:41, wrote:
On 10/05/2019 14:32, Jan Beulich wrote:
On 10.05.19 at 15:22, wrote:
On 10/05/2019 13:31, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -205,7 +205,7 @@ v
On 10/05/2019 15:05, Andrew Cooper wrote:
On 10/05/2019 15:02, Jan Beulich wrote:
On 10.05.19 at 15:46, wrote:
On 10/05/2019 14:41, Jan Beulich wrote:
On 10.05.19 at 15:34, wrote:
On 10/05/2019 14:21, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
@@ -1030,19 +1031,19 @@ long p2m_pt_a
On 10/05/2019 15:08, Julien Grall wrote:
>
>
> On 10/05/2019 15:05, Andrew Cooper wrote:
>> On 10/05/2019 15:02, Jan Beulich wrote:
>> On 10.05.19 at 15:46, wrote:
On 10/05/2019 14:41, Jan Beulich wrote:
On 10.05.19 at 15:34, wrote:
>> On 10/05/2019 14:21, Jan Beulich wrote:
While it already has a CONFIG_PV wrapped around its entire body, it is
still uselessly invoking mfn_to_gmfn(), which is about to be replaced.
Avoid morphing this code into even more suspicious shape and remove the
effectively dead code - translated mode has been made impossible for PV
quite some ti
>>> On 10.05.19 at 16:05, wrote:
> The overwhelming majority way of printing mfns is via:
>
> mfn %"PRI_mfn"
>
> which is almost fully consistent across the x86 code.
>
> Various bits of common code, and most of ARM code use variations of
> %#"PRI_mfn", and this ought to be fixed.
Oh, so you'r
Hi Jan,
Thank you for sending the patch! I will rebase my M2P series on top of this.
Cheers,
On 10/05/2019 15:12, Jan Beulich wrote:
While it already has a CONFIG_PV wrapped around its entire body, it is
still uselessly invoking mfn_to_gmfn(), which is about to be replaced.
Avoid morphing this
>>> On 10.05.19 at 16:04, wrote:
> On 10/05/2019 14:45, Jan Beulich wrote:
> On 10.05.19 at 15:41, wrote:
>>> The point here, we keep within the hypervisor the idea of what's valid or
>>> invalid. This allows us more flexibility on the value here (imagine we
>>> decide to
>>> change the valu
>>> On 10.05.19 at 16:05, wrote:
> On 10/05/2019 14:48, Jan Beulich wrote:
> On 10.05.19 at 15:41, wrote:
>>> On 10/05/2019 14:35, Jan Beulich wrote:
I didn't mean it to remain NULL. Common code doesn't dereference it
(and isn't supposed to), so I'd consider initializing it to some
On 10/05/2019 15:12, Jan Beulich wrote:
> While it already has a CONFIG_PV wrapped around its entire body, it is
> still uselessly invoking mfn_to_gmfn(), which is about to be replaced.
> Avoid morphing this code into even more suspicious shape and remove the
> effectively dead code - translated mo
On Fri, May 10, 2019 at 08:12:51AM -0600, Jan Beulich wrote:
> While it already has a CONFIG_PV wrapped around its entire body, it is
> still uselessly invoking mfn_to_gmfn(), which is about to be replaced.
> Avoid morphing this code into even more suspicious shape and remove the
> effectively dead
On 10/05/2019 15:14, Jan Beulich wrote:
On 10.05.19 at 16:05, wrote:
>> The overwhelming majority way of printing mfns is via:
>>
>> mfn %"PRI_mfn"
>>
>> which is almost fully consistent across the x86 code.
>>
>> Various bits of common code, and most of ARM code use variations of
>> %#"PRI_m
Hi Jan,
On 10/05/2019 15:19, Jan Beulich wrote:
On 10.05.19 at 16:04, wrote:
On 10/05/2019 14:45, Jan Beulich wrote:
On 10.05.19 at 15:41, wrote:
The point here, we keep within the hypervisor the idea of what's valid or
invalid. This allows us more flexibility on the value here (imagine we
On 09/05/2019 22:46, Julien Grall wrote:
Hi,
On 09/05/2019 21:32, Julien Grall wrote:
Hi,
On 09/05/2019 21:13, Stefano Stabellini wrote:
On Wed, 8 May 2019, Julien Grall wrote:
/* Release all __init and __initdata ranges to be reused */
diff --git a/xen/include/asm-arm/arm32/page.h
b/xen/
On Thu, May 9, 2019 at 10:19 AM Andrew Cooper wrote:
>
> On 09/05/2019 14:38, Tamas K Lengyel wrote:
> > Hi all,
> > I'm investigating an issue with altp2m that can easily be reproduced
> > and leads to a hypervisor deadlock when PML is available in hardware.
> > I haven't been able to trace down
Hi,
On 10/05/2019 15:21, Jan Beulich wrote:
On 10.05.19 at 16:05, wrote:
On 10/05/2019 14:48, Jan Beulich wrote:
On 10.05.19 at 15:41, wrote:
On 10/05/2019 14:35, Jan Beulich wrote:
I didn't mean it to remain NULL. Common code doesn't dereference it
(and isn't supposed to), so I'd consider
flight 135901 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135901/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd d790588164713d9ba45e47c59146adf123abcce1
baseline version:
freebsd b5832150770
On 5/10/19 5:42 PM, Tamas K Lengyel wrote:
On Thu, May 9, 2019 at 10:19 AM Andrew Cooper wrote:
On 09/05/2019 14:38, Tamas K Lengyel wrote:
Hi all,
I'm investigating an issue with altp2m that can easily be reproduced
and leads to a hypervisor deadlock when PML is available in hardware.
I have
On 10/05/2019 15:53, Razvan Cojocaru wrote:
> On 5/10/19 5:42 PM, Tamas K Lengyel wrote:
>> On Thu, May 9, 2019 at 10:19 AM Andrew Cooper
>> wrote:
>>>
>>> On 09/05/2019 14:38, Tamas K Lengyel wrote:
Hi all,
I'm investigating an issue with altp2m that can easily be reproduced
and le
On Fri, May 10, 2019 at 8:59 AM Andrew Cooper wrote:
>
> On 10/05/2019 15:53, Razvan Cojocaru wrote:
> > On 5/10/19 5:42 PM, Tamas K Lengyel wrote:
> >> On Thu, May 9, 2019 at 10:19 AM Andrew Cooper
> >> wrote:
> >>>
> >>> On 09/05/2019 14:38, Tamas K Lengyel wrote:
> Hi all,
> I'm inve
Le jeudi, mai 9, 2019 6:42 PM, Andrew Cooper a
écrit :
> Therefore, the conclusion to draw is that it is a logical bug somewhere.
>
> First of all - ensure you are using up-to-date microcode. The number of
> errata which have been discovered by people associated with the Xen
> community is large
Le jeudi, mai 9, 2019 8:08 PM, Tamas K Lengyel a écrit :
> > > > I already suggested to Mathieu to try to reproduce the issue using the
> > > > xen-access test tool that's in the Xen tree to cut out all that
> > > > complexity.
> >
> > xen-access is ok, but I've never encountered a situation where
If a domU has a qemu-xen instance attached, it is required to call qemus
"xen-save-devices-state" method. Without it, the receiving side of a PV or
PVH migration may be unable to lock the image:
xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
error: Failed to get "write
On 10/05/2019 16:17, Mathieu Tarral wrote:
> Le jeudi, mai 9, 2019 6:42 PM, Andrew Cooper a
> écrit :
>> Therefore, the conclusion to draw is that it is a logical bug somewhere.
>>
>> First of all - ensure you are using up-to-date microcode. The number of
>> errata which have been discovered by
On 10/05/2019 16:09, Tamas K Lengyel wrote:
> On Fri, May 10, 2019 at 8:59 AM Andrew Cooper
> wrote:
>> On 10/05/2019 15:53, Razvan Cojocaru wrote:
>>> On 5/10/19 5:42 PM, Tamas K Lengyel wrote:
On Thu, May 9, 2019 at 10:19 AM Andrew Cooper
wrote:
> On 09/05/2019 14:38, Tamas K Len
Hello, all
gentle reminder...
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Fri, May 10, 2019 at 9:21 AM Andrew Cooper wrote:
>
> On 10/05/2019 16:09, Tamas K Lengyel wrote:
> > On Fri, May 10, 2019 at 8:59 AM Andrew Cooper
> > wrote:
> >> On 10/05/2019 15:53, Razvan Cojocaru wrote:
> >>> On 5/10/19 5:42 PM, Tamas K Lengyel wrote:
> On Thu, May 9, 2019 at 10:19
On 10/05/2019 16:29, Oleksandr wrote:
Hello, all
gentle reminder...
This is on my long queue of patches to review. Any help reviewing the on-going
series will help.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenprojec
On 10/05/2019 16:29, Tamas K Lengyel wrote:
> On Fri, May 10, 2019 at 9:21 AM Andrew Cooper
> wrote:
>> On 10/05/2019 16:09, Tamas K Lengyel wrote:
>>> On Fri, May 10, 2019 at 8:59 AM Andrew Cooper
>>> wrote:
On 10/05/2019 15:53, Razvan Cojocaru wrote:
> On 5/10/19 5:42 PM, Tamas K Len
Since pci_dev already has a pci_sbdf_t field switch the capability
related functions SBDF parameters to a single pci_sbdf_t parameter.
No functional change expected.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien
pci_dev already uses pci_sbdf_t, so propagate the usage of the type to
pci_conf functions in order to shorten the calls when made from a
pci_dev struct.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian J
This avoids code duplication between the helpers.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/x86_64/pci.c | 140 --
1 file changed, 57 insertions(+), 83 deletions(-)
dif
On 10/05/2019 17:10, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
> index aeb5a70104..15cfe8d057 100644
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -688,8 +688,8 @@ static int vpci_msi_update(const struct pci_dev *pdev,
> uint32_t
The new format specifier is '%pp', and prints a pci_sbdf_t using the
seg:bus:dev.func format. Replace all SBDFs printed using
'%04x:%02x:%02x.%u' to use the new format specifier.
No functional change expected.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jacks
This patch replaces the seg, bus and devfn fields of the struct and
fixes the callers. While there instances of u have also been
replaced with uint_t.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jac
pci: expand usage of pci_sbdf_t
Start by switching the seg, bus and devfn fields of pci_dev to a single
pci_sdbf_t field, and fixup the users. Also change the pci_conf and pci
capabilities related functions to use pci_sbdf_t as parameter instead of
passing the sbdf in multiple parameters. Finally
flight 135900 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135900/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail in 135790 pass in
135900
test-amd64-i386-libvirt-xsm 21
On 10.05.19 18:45, Julien Grall wrote:
Hi, Julien
On 10/05/2019 16:29, Oleksandr wrote:
Hello, all
gentle reminder...
This is on my long queue of patches to review. Any help reviewing the
on-going series will help.
Oh, I see. Fair enough.
Cheers,
--
Regards,
Oleksandr Tyshche
On Fri, 10 May 2019, Julien Grall wrote:
> On 09/05/2019 22:46, Julien Grall wrote:
> > Hi,
> >
> > On 09/05/2019 21:32, Julien Grall wrote:
> > > Hi,
> > >
> > > On 09/05/2019 21:13, Stefano Stabellini wrote:
> > > > On Wed, 8 May 2019, Julien Grall wrote:
> > > > > /* Release all __init and _
For a domain which has been using watchdogs, but wants to cleanly reboot,
stopping all active timers is necessary to avoid crashing late during
shutdown.
The number of watchdogs isn't part of Xen's ABI, so to simplify cleanup and
error handling logic, support using id = 0, timeout = 0 to deactivat
This is a mostly to address a corner case when using watchdogs, when a domain
wishes to cease fencing activites and cleanly reboot.
Patches 1 to 3 are just code improvements in domain_watchdog(). Patch 4
introduces the new functionality.
Andrew Cooper (4):
xen/watchdog: Fold exit paths to have
This is mostly to simplify future logical changes, but it does come with a
modest redunction in compiled code size (-55, 345 => 290).
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dun
All modifications to the watchdog_inuse_map happen with d->watchdog_lock held,
so there are no concurrency problems to deal with.
Furthermore, there is no need to use a loop to locate the next available
watchdog. As the bitmap is currently 2 bits wide and is stored in a uint32_t,
the next availab
By rearranging the logic, the timer allocation loop can reuse the common timer
arming/clearing logic. This results in easier to follow code, and a modest
reduction in compiled code size (-64, 290 => 226).
For domains which use watchdogs, the overwhemling majoriy of hypercalls will
be re-arming an
Hi,
On 10/05/2019 18:57, Stefano Stabellini wrote:
> On Fri, 10 May 2019, Julien Grall wrote:
>> On 09/05/2019 22:46, Julien Grall wrote:
>>> Hi,
>>>
>>> On 09/05/2019 21:32, Julien Grall wrote:
Hi,
On 09/05/2019 21:13, Stefano Stabellini wrote:
> On Wed, 8 May 2019, Julien Gral
On Fri, 3 May 2019, Ian Jackson wrote:
> Adding Stefano for archaelogical reasons.
>
> Anthony PERARD writes ("[PATCH] tools/Makefile: Fix build of QEMU, remove
> --source-path"):
> > Following QEMU's commit 79d77bcd36 (configure: Remove --source-path
> > option), Xen's build system fails to buil
On Tue, 7 May 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 4/30/19 10:02 PM, Stefano Stabellini wrote:
> > Reserved memory regions are automatically remapped to dom0. Their device
> > tree nodes are also added to dom0 device tree. However, the dom0 memory
> > node is not currently extended to co
flight 135902 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135902/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 134015
test-amd64-amd64-libv
Hi,
On 10/05/2019 21:51, Stefano Stabellini wrote:
> On Tue, 7 May 2019, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 4/30/19 10:02 PM, Stefano Stabellini wrote:
>>> Reserved memory regions are automatically remapped to dom0. Their device
>>> tree nodes are also added to dom0 device tree. However,
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, April 26, 2019 12:45 AM
>
> * Use XFREE() instead of opencoding it in nvmx_cpu_dead()
> * Avoid redundant evaluations of per_cpu()
> * Don't allocate vvmcs_buf at all if it isn't going to be used. It is never
>touched
> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Thursday, May 2, 2019 7:52 AM
>
> Currently the gs_shadow value is only cached when the vCPU is being
> scheduled
> out by Xen. Reporting this (usually) stale value through vm_event is
> incorrect,
> since it doesn't represent the actua
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, May 8, 2019 9:16 PM
>
> >>> On 08.05.19 at 15:10, wrote:
> > All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
> > fields, and hence ought to be called with the descriptor lock held in
> > addition to vector_lock
flight 135911 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail in 135805 REGR. vs.
133989
Tests wh
Hi all,
following the recent discussion, we had on IRC and the action I had in the March
community call, I wanted to make a proposal related to the file format to track
files. I am not yet submitting a fully formed patch as there may be differing
opinions about the file format and name of the file
Dear Community Members,
we are excited to unveil the Xen Project Developer and Design Summit program
and speaker schedule [1]. The Xen Project Developer and Design Summit
brings together the Xen Project’s community of developers and power
users for their annual conference.
1 - 100 of 101 matches
Mail list logo
