Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Ian Campbell]

On Tue, 2015-12-01 at 08:41 +0100, Juergen Gross wrote:
> >> I'm not quite sure what to make of this, in particular I don't see
> anything
> >> in kexec.c which obviously looks after unmapping the heap or brk
> areas.
> > 
> > Nah, this backtrace shows a normal allocation path while
> > uncompressing the kernel image. I'd expect something like that.
> > Why shouldn't mini-os make use of pfn 4d81 somewhere?

That pfn ends up right in the middle of the next-kernels vaddr mapping,
so at best it indicates some sort of disconnect/overlap between the
mini-os memory allocator and the domain-builder memory allocator.

Since it seems to be in the middle of the padding area (which might
have been new in ea7c8a3d0e82, I'm not sure, it seems to be more
explicit at the least) it occurred to me on the way home last night
that maybe we need to unmap the padding area as well.

I'll try that and your suggested patch below as well once I get to the
office this morning.

> > 
> > I guess there is something wrong either in mini-os's memory
> > allocator (not very likely) or in kexec_allocate(). I'll try to
> > check those.
> 
> Hmm, kexec_allocate() seems to be a little bit fishy.
> 
> I suspect a problem in the loop for the case new_pfn == i. I think
> in this case the p2m list will be written with a wrong entry.
> 
> Ian, could you verify via:
> 
> diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
> index 8fd9ff9..9421023 100644
> --- a/stubdom/grub/kexec.c
> +++ b/stubdom/grub/kexec.c
> @@ -131,6 +131,8 @@ int kexec_allocate(struct xc_dom_image *dom)
>   /* Store destination PFN of currently requested page. */
>   pages_moved2pfns[i] = new_pfn;
> 
> + BUG_ON(new_pfn == i);
> +
>   /* Put old page at new PFN */
>   dom->p2m_host[new_pfn] = old_mfn;
> 
> 
> Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Ian Campbell]

On Tue, 2015-12-01 at 08:15 +0100, Juergen Gross wrote:
> 
> BTW: up to now I haven't managed to reproduce your problem. My
> domains are just booting fine up to now. Is there a way I could
> get the domain image which is failing? Maybe I could just try
> to use that on my test machine with the same domain config you are
> using.

I think it should be sufficient just to drop the Debian kernel into an
empty filesystem attached to the guest, just doing "kernel
(hd0,0)/boot/vmlinuz ; boot" from the grub command line seems to
replicate the issue for me. Probably easier than actually going through
an installation.

I can send you the vmlinuz if you think that approach is worth trying.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Juergen Gross]

On 01/12/15 09:30, Ian Campbell wrote:
> On Tue, 2015-12-01 at 08:41 +0100, Juergen Gross wrote:
 I'm not quite sure what to make of this, in particular I don't see
>> anything
 in kexec.c which obviously looks after unmapping the heap or brk
>> areas.
>>>
>>> Nah, this backtrace shows a normal allocation path while
>>> uncompressing the kernel image. I'd expect something like that.
>>> Why shouldn't mini-os make use of pfn 4d81 somewhere?
> 
> That pfn ends up right in the middle of the next-kernels vaddr mapping,
> so at best it indicates some sort of disconnect/overlap between the
> mini-os memory allocator and the domain-builder memory allocator.

I don't think so.

mini-os just allocates single pages and keeps the relation to the
(future) pfn of that page. The p2m list is adjusted later to move the
allocated page to that pfn before activating the new kernel.

> Since it seems to be in the middle of the padding area (which might
> have been new in ea7c8a3d0e82, I'm not sure, it seems to be more
> explicit at the least) it occurred to me on the way home last night
> that maybe we need to unmap the padding area as well.

We do. The page tables need to be unmapped independently as they
have been mapped explicitly during setup_pgtables(dom). All the
mini-os mappings are removed in a loop just after that.

> I'll try that and your suggested patch below as well once I get to the
> office this morning.

Thanks.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms

[Dario Faggioli]

On Sun, 2015-11-29 at 11:44 -0500, Meng Xu wrote:
> 2015-11-29 11:27 GMT-05:00 Dario Faggioli 
> :
> > 
> > Mmmm... As I said many times, I don't remember much of all those RT
> > schedulability formulas, but, is really that simple?
> 
> Ah, let me clarify...
> It is not that simple. ;-) I just simplify it, hoping it can simplify
> the problem and highlight the possible reason.
> 
Ok, glad to know I haven't completely lost my mind, or anything like
that! :-)

> > I mean, if the in-
> > guest scheduling algorithm is global (e.g., global-EDF), the task
> > could
> > migrate, couldn't it?
> 
> Yes. If these partial VCPUs happen to be scheduled "sequentially",
> the
> OS inside VM can migrate the task and make the task keep running. But
> that is not the worst-case for the OS.
> 
Right, I see it now, and (FWIW) I absolutely agree with the worst-case
analysis you provided (thanks). I did not get the fact that you were
talking about the worst-case, sorry for the noise. :-D

> The detailed illustration of the worst case scenario is at Arvind's
> paper: http://link.springer.com/article/10.1007%2Fs11241-009-9073-x
> My latest journal paper
> (http://link.springer.com/article/10.1007%2Fs11241-015-9223-2)
> tighten
> the resource supply bound function of the MPR model. I believe the
> equations are too boring to most of people in the mailing list.
> 
> So let's avoid the complex equations here. ;-)
> 
Thanks for this too! :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] x86/VPMU: Support only versions 2 and 3 of architectural performance monitoring

[Dietmar Hahn]

Am Montag 30 November 2015, 13:38:40 schrieb Boris Ostrovsky:
> We need to have at least version 2 since it's the first version to
> support various control and status registers (such as
> MSR_CORE_PERF_GLOBAL_CTRL) that VPMU relies on always having.
> 
> With explicit testing for PMU version we can now remove CPUID model
> check.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  xen/arch/x86/cpu/vpmu_intel.c | 55 
> +++
>  1 file changed, 8 insertions(+), 47 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
> index d5ea7fe..bb4ddcc 100644
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -955,59 +955,20 @@ int vmx_vpmu_initialise(struct vcpu *v)
>  int __init core2_vpmu_init(void)
>  {
>  u64 caps;
> +unsigned int version = 0;
>  
> -if ( current_cpu_data.x86 != 6 )
> +if ( current_cpu_data.cpuid_level >= 0xa )
> +version = cpuid_eax(0xa) & 0xff;
> +if ( (version != 2) && (version != 3) )
>  {
> -printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
> +printk(XENLOG_WARNING "VPMU: version %d is not supported\n", 
> version);
>  return -EINVAL;

But this means that all (newer?) processors with version=4 are not supported
even though the SDM 3B tells:
"Processors supporting architectural performance monitoring version 4 also
 supports version 1, 2, and 3, ..."

Shold we not only write a hint that version 4 capabilities are not supported
and fake this cpuid-flag for the guests to the version 3?

Dietmar.

>  }
>  
> -switch ( current_cpu_data.x86_model )
> +if ( current_cpu_data.x86 != 6 )
>  {
> -/* Core2: */
> -case 0x0f: /* original 65 nm celeron/pentium/core2/xeon, 
> "Merom"/"Conroe" */
> -case 0x16: /* single-core 65 nm celeron/core2solo 
> "Merom-L"/"Conroe-L" */
> -case 0x17: /* 45 nm celeron/core2/xeon "Penryn"/"Wolfdale" */
> -case 0x1d: /* six-core 45 nm xeon "Dunnington" */
> -
> -case 0x2a: /* SandyBridge */
> -case 0x2d: /* SandyBridge, "Romley-EP" */
> -
> -/* Nehalem: */
> -case 0x1a: /* 45 nm nehalem, "Bloomfield" */
> -case 0x1e: /* 45 nm nehalem, "Lynnfield", "Clarksfield", "Jasper 
> Forest" */
> -case 0x2e: /* 45 nm nehalem-ex, "Beckton" */
> -
> -/* Westmere: */
> -case 0x25: /* 32 nm nehalem, "Clarkdale", "Arrandale" */
> -case 0x2c: /* 32 nm nehalem, "Gulftown", "Westmere-EP" */
> -case 0x2f: /* 32 nm Westmere-EX */
> -
> -case 0x3a: /* IvyBridge */
> -case 0x3e: /* IvyBridge EP */
> -
> -/* Haswell: */
> -case 0x3c:
> -case 0x3f:
> -case 0x45:
> -case 0x46:
> -
> -/* Broadwell */
> -case 0x3d:
> -case 0x4f:
> -case 0x56:
> -
> -/* future: */
> -case 0x4e:
> -
> -/* next gen Xeon Phi */
> -case 0x57:
> -break;
> -
> -default:
> -printk(XENLOG_WARNING "VPMU: Unsupported CPU model %#x\n",
> -   current_cpu_data.x86_model);
> -return -EINVAL;
> +printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
> +return -EINVAL;
>  }
>  
>  arch_pmc_cnt = core2_get_arch_pmc_count();
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Ian Campbell]

On Tue, 2015-12-01 at 09:53 +0100, Juergen Gross wrote:
> On 01/12/15 09:30, Ian Campbell wrote:
> > On Tue, 2015-12-01 at 08:41 +0100, Juergen Gross wrote:
> > > > > I'm not quite sure what to make of this, in particular I don't
> > > > > see
> > > anything
> > > > > in kexec.c which obviously looks after unmapping the heap or brk
> > > areas.
> > > > 
> > > > Nah, this backtrace shows a normal allocation path while
> > > > uncompressing the kernel image. I'd expect something like that.
> > > > Why shouldn't mini-os make use of pfn 4d81 somewhere?
> > 
> > That pfn ends up right in the middle of the next-kernels vaddr mapping,
> > so at best it indicates some sort of disconnect/overlap between the
> > mini-os memory allocator and the domain-builder memory allocator.
> 
> I don't think so.
> 
> mini-os just allocates single pages and keeps the relation to the
> (future) pfn of that page. The p2m list is adjusted later to move the
> allocated page to that pfn before activating the new kernel.

Ah, I was wondering how it could possibly work so I half expected I must be
missing something.

> > Since it seems to be in the middle of the padding area (which might
> > have been new in ea7c8a3d0e82, I'm not sure, it seems to be more
> > explicit at the least) it occurred to me on the way home last night
> > that maybe we need to unmap the padding area as well.
> 
> We do. The page tables need to be unmapped independently as they
> have been mapped explicitly during setup_pgtables(dom). All the
> mini-os mappings are removed in a loop just after that.

"a loop" is this:
/* Unmap day0 pages to avoid having a r/w mapping of the future page table 
*/
   for (pfn = 0; pfn < allocated; pfn++)
munmap((void*) pages[pfn], PAGE_SIZE);

In my debugging this extends only to the end of the actual mappings, not to
the end of the padding, e.g. for me it is extending to "Unmap pfns 0 ..
0x4c0f" while the unexpected PT pfn is at 0x4d80 and the padding area
extends to pfn 0x5000.

> > I'll try that and your suggested patch below as well once I get to the
> > office this morning.
> 
> Thanks.

The BUG_ON doesn't seem to be triggering. I'm not seeing pfn==0x4d80 going
anywhere near kexec_allocate, the highest is 0x4c0f.

Maybe the issue is that the ->allocate hook (==kexec_allocate) isn't called
from xc_dom_alloc_pad?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Ian Campbell]

On Tue, 2015-12-01 at 10:01 +, Ian Campbell wrote:
> 
> > > I'll try that and your suggested patch below as well once I get to the
> > > office this morning.
> > 
> > Thanks.
> 
> The BUG_ON doesn't seem to be triggering. I'm not seeing pfn==0x4d80 going
> anywhere near kexec_allocate, the highest is 0x4c0f.
> 
> Maybe the issue is that the ->allocate hook (==kexec_allocate) isn't called
> from xc_dom_alloc_pad?

That seems like it might be the answer, this patchlet fixes it for me:

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 5d6c3ba..6d3f97a 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -579,7 +579,13 @@ static int xc_dom_alloc_pad(struct xc_dom_image *dom, 
xen_vaddr_t boundary)
 }
 pages = (boundary - dom->virt_alloc_end) / page_size;
 
-return xc_dom_chk_alloc_pages(dom, "padding", pages);
+if ( xc_dom_chk_alloc_pages(dom, "padding", pages) )
+return -1;
+
+if (dom->allocate)
+dom->allocate(dom);
+
+return 0;
 }
 
 int xc_dom_alloc_segment(struct xc_dom_image *dom,

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: correct domain builder for 64 bit guest with 32 bit tools

[Wei Liu]

On Tue, Dec 01, 2015 at 08:49:49AM +0100, Juergen Gross wrote:
> Commit 8c45adec18e0512c3d34dcafb13414ecba21be6a ("create unmapped
> initrd in domain builder if supported") introduced an error for
> building a 64 bit guest with a 32 bit toolset.
> 
> The initrd start address and size where stored in an unsigned long
> instead of using a 64 bit type.
> 
> Signed-off-by: Juergen Gross 
> Tested-by: Boris Ostrovsky 

Acked-by: Wei Liu 

Thanks for fixing this.

> ---
>  tools/libxc/include/xc_dom.h | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 2176216..fd8c5e8 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -98,9 +98,14 @@ struct xc_dom_image {
>  xen_vaddr_t virt_alloc_end;
>  xen_vaddr_t bsd_symtab_start;
>  
> -/* initrd parameters as specified in start_info page */
> -unsigned long initrd_start;
> -unsigned long initrd_len;
> +/*
> + * initrd parameters as specified in start_info page
> + * Depending on capabilities of the booted kernel this may be a virtual
> + * address or a pfn. Type is neutral and large enough to hold a virtual
> + * address of a 64 bit kernel even with 32 bit toolstack.
> + */
> +uint64_t initrd_start;
> +uint64_t initrd_len;
>  
>  unsigned int alloc_bootstack;
>  xen_vaddr_t virt_pgtab_end;
> -- 
> 2.6.2
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms

[Lars Kurth]

I wonder whether we need to add some health warnings and recommended background 
reading to http://wiki.xenproject.org/wiki/RTDS-Based-Scheduler
Lars

> On 1 Dec 2015, at 08:59, Dario Faggioli  wrote:
> 
> On Sun, 2015-11-29 at 11:44 -0500, Meng Xu wrote:
>> 2015-11-29 11:27 GMT-05:00 Dario Faggioli 
>> :
>>>  
>>> Mmmm... As I said many times, I don't remember much of all those RT
>>> schedulability formulas, but, is really that simple?
>> 
>> Ah, let me clarify...
>> It is not that simple. ;-) I just simplify it, hoping it can simplify
>> the problem and highlight the possible reason.
>> 
> Ok, glad to know I haven't completely lost my mind, or anything like
> that! :-)
> 
>>> I mean, if the in-
>>> guest scheduling algorithm is global (e.g., global-EDF), the task
>>> could
>>> migrate, couldn't it?
>> 
>> Yes. If these partial VCPUs happen to be scheduled "sequentially",
>> the
>> OS inside VM can migrate the task and make the task keep running. But
>> that is not the worst-case for the OS.
>> 
> Right, I see it now, and (FWIW) I absolutely agree with the worst-case
> analysis you provided (thanks). I did not get the fact that you were
> talking about the worst-case, sorry for the noise. :-D
> 
>> The detailed illustration of the worst case scenario is at Arvind's
>> paper: http://link.springer.com/article/10.1007%2Fs11241-009-9073-x
>> My latest journal paper
>> (http://link.springer.com/article/10.1007%2Fs11241-015-9223-2)
>> tighten
>> the resource supply bound function of the MPR model. I believe the
>> equations are too boring to most of people in the mailing list.
>> 
>> So let's avoid the complex equations here. ;-)
>> 
> Thanks for this too! :-)
> 
> Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH XEN v5 13/23] tools: Refactor foreign memory mapping into libxenforeignmemory

[Paul Durrant]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 30 November 2015 09:52
> To: Paul Durrant; Andrew Cooper; Ian Jackson
> Cc: Wei Liu; xen-devel@lists.xen.org; win-pv-de...@lists.xenproject.org
> Subject: Re: [PATCH XEN v5 13/23] tools: Refactor foreign memory mapping
> into libxenforeignmemory
> 
> On Sun, 2015-11-29 at 09:54 +, Paul Durrant wrote:
> > > -Original Message-
> > [snip]
> > > > C99 was 16 years ago now, I'm struggling to think of a reason not to
> > > > move
> > > > the baseline for tools stuff at least to that.
> > > >
> > > > https://en.wikipedia.org/wiki/Visual_C%2B%2B might be one such
> reason
> > > > I
> > > > suppose, although I'm not convinced a libvchan port to Windows, even
> > > > if
> > > not
> > > > entirely hypothetical, would be using any of xen.git/tools/libs/*
> > > > rather
> > > > than the equivalent frameworks provided by the Windows PV drivers.
> > >
> > > It would be nice to at least be able to use the same header files, for
> > > ease of porting userspace software.
> > >
> >
> > It's possible that libvchan on Windows will make use of the tools/libs
> > headers. As Andy says it would ease porting client software.
> >
> > > In this case, VLAs are just being used as an aid for the compiler to
> > > spot errors.  It doesn't change the API/ABI, and could be #ifdef'd
> > > around, if we care both for using C99 in general, and Windows support.
> > >
> >
> > We still compile with VS2012 in Citrix and Xen Project uses VS2013 so we
> > can't rely on C99. A #ifdef here does seem like the best solution.
> 
> Would you expect new projects (i.e. stuff based on tools/libs) to continue
> to have requirements to build with those older versions? (Although with
> Andy's link saying even VS2015 doesn't do VLAs maybe it is a bit moot).
> 

It would certainly be preferable to have something that did build under a 
sufficiently old C standard to cover as many environments as is reasonable, and 
I think any supported MSVC build environment should be included in that set 
(although I have no problem using #ifdefs to achieve that).

> I don't think using VLA here is worth an ifdef, but I think it is worth
> reordering the arguments such that once we end up with a new enough
> compiler baseline (in $donkeys years) we can switch without changing the
> ABI (I think that's the case).
> 

IIUC correctly the use of VLAs does not change the calling convention in any 
way, right? It would still mean a pointer to err_out is passed and the use of a 
VLA is so that bounds checking can be performed?
I certainly don't think we should get ourselves into a situation where 
additions to compilers or C standards do cause changes in the ABI (and we 
already have to be careful with Windows 32-bit since it defaults to pascal 
calling convention).

  Paul

> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [qemu-mainline test] 65237: regressions - FAIL

[Ian Campbell]

On Mon, 2015-11-30 at 18:47 +, Anthony PERARD wrote:
> On Mon, Nov 30, 2015 at 09:40:28AM +, osstest service owner wrote:
> > flight 65237 qemu-mainline real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/65237/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 
> > 64579
> >  test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. 
> > vs. 64579
> 
> In this test, qemu SIGABRT with "Bad ram offset efffd000" as an error
> message. The test started to fail when osstest started to test with a guest
> with 5000 of memory instead of 768.

That's still a QEMU and/or Xen bug though, right?

IOW you aren't trying to suggest this is an osstest bug, I think.

NB the size of the guest ram depends on the amount of host RAM available,
so this will vary across hosts.

The apparent switch to 5000 for test-amd64-i386-xl-qemuu-ovmf-amd64 was
from merlot1 starting in flight 65078, but there was a pass on merlot1
at 63741. My guess is that a change in one of the other trees between those
two has exposed the issue.

The test-amd64-i386-xl-qemuu-debianhvm-amd64 case[1] started in 65147 when
it ran on nocera1, but nocera* only went into service last week and haven't
run any flights on this branch before now.

The bisector is having a look at the merlot case[2], there are some interim
progress reports on the osstest-putput list[3] (search for 
test-amd64-i386-xl-qemuu-ovmf-amd64).

Looking at the complexity of the graph it'll probably take a little while
to reach a verdict, although it does appear to be making some progress.

Ian.

[0] 
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-ovmf-amd64/qemu-mainline.html
[1] 
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64/qemu-mainline.html
[2] 
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install.html
[3] 
http://lists.xenproject.org/archives/html/osstest-output/2015-11/threads.html

http://lists.xenproject.org/archives/html/osstest-output/2015-12/threads.html


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Wei Liu]

On Tue, Dec 01, 2015 at 10:04:38AM +, Ian Campbell wrote:
> On Tue, 2015-12-01 at 10:01 +, Ian Campbell wrote:
> > 
> > > > I'll try that and your suggested patch below as well once I get to the
> > > > office this morning.
> > > 
> > > Thanks.
> > 
> > The BUG_ON doesn't seem to be triggering. I'm not seeing pfn==0x4d80 going
> > anywhere near kexec_allocate, the highest is 0x4c0f.
> > 
> > Maybe the issue is that the ->allocate hook (==kexec_allocate) isn't called
> > from xc_dom_alloc_pad?
> 
> That seems like it might be the answer, this patchlet fixes it for me:
> 
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index 5d6c3ba..6d3f97a 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -579,7 +579,13 @@ static int xc_dom_alloc_pad(struct xc_dom_image *dom, 
> xen_vaddr_t boundary)
>  }
>  pages = (boundary - dom->virt_alloc_end) / page_size;
>  
> -return xc_dom_chk_alloc_pages(dom, "padding", pages);
> +if ( xc_dom_chk_alloc_pages(dom, "padding", pages) )
> +return -1;
> +
> +if (dom->allocate)
> +dom->allocate(dom);
> +
> +return 0;
>  }
>  
>  int xc_dom_alloc_segment(struct xc_dom_image *dom,

Currently there are three places that call dom->allocate (if we include
the call in the proposed diff). I think it would be better if we push
dom->allocate down to xc_dom_chk_alloc_pages, then refactor
xc_dom_alloc_page to use xc_dom_chk_alloc_pages.

Just some thought after a quick look at the code. I will see what I can
do after confirming this is the culprit.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 65252: regressions - FAIL

[osstest service owner]

flight 65252 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65252/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 64579
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
64579

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  6 xen-bootfail pass in 65237

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 64579
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 64579

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail in 65237 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass

version targeted for testing:
 qemuu714487515dbe0c65d5904251e796cd3a5b3579fb
baseline version:
 qemuu9be060f5278dc0d732ebfcf2bf0a293f88b833eb

Last test of basis64579  2015-11-17 15:37:49 Z   13 days
Failing since 64797  2015-11-19 03:03:30 Z   12 days   11 attempts
Testing same since65167  2015-11-27 19:59:25 Z3 days3 attempts


People who touched revisions under test:
  "Dr. David Alan Gilbert" 
  "Eugene (jno) Dvurechenski" 
  Alberto Garcia 
  Alistair Francis 
  Andreas Färber 
  Andrew Baumann 
  Anthony PERARD 
  Bandan Das 
  Daniel P. Berrange 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eric Blake 
  Eugene (jno) Dvurechenski 
  Fam Zheng 
  François Baldassari 
  Gerd Hoffmann 
  Greg Kurz 
  Ildar Isaev 
  James Hogan 
  Jason J. Herne 
  Jason Wang 
  John Arbuckle 
  John Clarke 
  John Snow 
  Juan Quintela 
  Kevin Wolf 
  Leon Alrae 
  Marc-André Lureau 
  Markus Armbruster 
  Max Reitz 
  Michael Roth 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Pavel Fedin 
  Peter Lieven 
  Peter Maydell 
  Programmingkid 
  Rabin Vincent 
  Ricard Wanderlof 
  Ricard Wanderlöf 
  Richard Henderson 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Fedorov 
  Stefan Hajnoczi 
  Stefan Weil 
  Stefano Dong (董兴水) 
  Stefano Stabellini 
  Victor Kaplansky 
  Vladimir Sementsov-Ogievskiy 
  Wen Congyang 
  Yuanhan Liu 
  Yuri Pudgorodskiy 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pa

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Ian Campbell]

On Tue, 2015-12-01 at 10:21 +, Wei Liu wrote:
> On Tue, Dec 01, 2015 at 10:04:38AM +, Ian Campbell wrote:
> > On Tue, 2015-12-01 at 10:01 +, Ian Campbell wrote:
> > > 
> > > > > I'll try that and your suggested patch below as well once I get
> > > > > to the
> > > > > office this morning.
> > > > 
> > > > Thanks.
> > > 
> > > The BUG_ON doesn't seem to be triggering. I'm not seeing pfn==0x4d80
> > > going
> > > anywhere near kexec_allocate, the highest is 0x4c0f.
> > > 
> > > Maybe the issue is that the ->allocate hook (==kexec_allocate) isn't
> > > called
> > > from xc_dom_alloc_pad?
> > 
> > That seems like it might be the answer, this patchlet fixes it for me:
> > 
> > diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> > index 5d6c3ba..6d3f97a 100644
> > --- a/tools/libxc/xc_dom_core.c
> > +++ b/tools/libxc/xc_dom_core.c
> > @@ -579,7 +579,13 @@ static int xc_dom_alloc_pad(struct xc_dom_image
> > *dom, xen_vaddr_t boundary)
> >  }
> >  pages = (boundary - dom->virt_alloc_end) / page_size;
> >  
> > -return xc_dom_chk_alloc_pages(dom, "padding", pages);
> > +if ( xc_dom_chk_alloc_pages(dom, "padding", pages) )
> > +return -1;
> > +
> > +if (dom->allocate)
> > +dom->allocate(dom);
> > +
> > +return 0;
> >  }
> >  
> >  int xc_dom_alloc_segment(struct xc_dom_image *dom,
> 
> Currently there are three places that call dom->allocate (if we include
> the call in the proposed diff). I think it would be better if we push
> dom->allocate down to xc_dom_chk_alloc_pages, then refactor
> xc_dom_alloc_page to use xc_dom_chk_alloc_pages.

Yes, I was thinking along the same lines after the quick hack above
confirmed it.

> Just some thought after a quick look at the code. I will see what I can
> do after confirming this is the culprit.

I don't mind finishing this one off (although I'm also equally happy to
hand it over ;-))

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Andrew Cooper]

On 30/11/15 21:22, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 26, 2015 at 01:55:57PM +, Andrew Cooper wrote:
>> On 26/11/15 13:48, Malcolm Crossley wrote:
>>> On 26/11/15 13:46, Jan Beulich wrote:
>>> On 25.11.15 at 11:28,  wrote:
> The problem is that SandyBridge IOMMUs advertise 2M support and do
> function with it, but cannot cache 2MB translations in the IOTLBs.
>
> As a result, attempting to use 2M translations causes substantially
> worse performance than 4K translations.
 Btw - how does this get explained? At a first glance, even if 2Mb
 translations don't get entered into the TLB, it should still be one
 less page table level to walk for the IOMMU, and should hence
 nevertheless be a benefit. Yet you even say _substantially_
 worse performance results.
>>> There is a IOTLB for the 4K translation so if you only use 4K
>>> translations then you get to take advantage of the IOTLB.
>>>
>>> If you use the 2Mb translation then a page table walk has to be
>>> performed every time there's a DMA access to that region of the BFN
>>> address space.
>> Also remember that a high level dma access (from the point of view of a
>> driver) will be fragmented at the PCIe max packet size, which is
>> typically 256 bytes.
>>
>> So by not caching the 2Mb translation, a dma access of 4k may undergo 16
>> pagetable walks, one for each PCIe packet.
>>
>> We observed that using 2Mb mappings results in a 40% overhead, compared
>> to using 4k mappings, from the point of view of a sample network workload.
> How did you observe this? I am mighty curious what kind of performance tools
> you used to find this  as I would love to figure out if some of the issues
> we have seen are related to this?

The 40% difference is just in terms of network throughput of a VF, given
a workload which can normally saturate line rate on the card.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Wei Liu]

On Tue, Dec 01, 2015 at 10:31:20AM +, Ian Campbell wrote:
> On Tue, 2015-12-01 at 10:21 +, Wei Liu wrote:
> > On Tue, Dec 01, 2015 at 10:04:38AM +, Ian Campbell wrote:
> > > On Tue, 2015-12-01 at 10:01 +, Ian Campbell wrote:
> > > > 
> > > > > > I'll try that and your suggested patch below as well once I get
> > > > > > to the
> > > > > > office this morning.
> > > > > 
> > > > > Thanks.
> > > > 
> > > > The BUG_ON doesn't seem to be triggering. I'm not seeing pfn==0x4d80
> > > > going
> > > > anywhere near kexec_allocate, the highest is 0x4c0f.
> > > > 
> > > > Maybe the issue is that the ->allocate hook (==kexec_allocate) isn't
> > > > called
> > > > from xc_dom_alloc_pad?
> > > 
> > > That seems like it might be the answer, this patchlet fixes it for me:
> > > 
> > > diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> > > index 5d6c3ba..6d3f97a 100644
> > > --- a/tools/libxc/xc_dom_core.c
> > > +++ b/tools/libxc/xc_dom_core.c
> > > @@ -579,7 +579,13 @@ static int xc_dom_alloc_pad(struct xc_dom_image
> > > *dom, xen_vaddr_t boundary)
> > >  }
> > >  pages = (boundary - dom->virt_alloc_end) / page_size;
> > >  
> > > -return xc_dom_chk_alloc_pages(dom, "padding", pages);
> > > +if ( xc_dom_chk_alloc_pages(dom, "padding", pages) )
> > > +return -1;
> > > +
> > > +if (dom->allocate)
> > > +dom->allocate(dom);
> > > +
> > > +return 0;
> > >  }
> > >  
> > >  int xc_dom_alloc_segment(struct xc_dom_image *dom,
> > 
> > Currently there are three places that call dom->allocate (if we include
> > the call in the proposed diff). I think it would be better if we push
> > dom->allocate down to xc_dom_chk_alloc_pages, then refactor
> > xc_dom_alloc_page to use xc_dom_chk_alloc_pages.
> 
> Yes, I was thinking along the same lines after the quick hack above
> confirmed it.
> 
> > Just some thought after a quick look at the code. I will see what I can
> > do after confirming this is the culprit.
> 
> I don't mind finishing this one off (although I'm also equally happy to
> hand it over ;-))

Already working on a patch. :-)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv3] xen/gntdev: add ioctl for grant copy

[David Vrabel]

On 30/11/15 21:39, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 27, 2015 at 05:17:05PM +, David Vrabel wrote:
>> Add IOCTL_GNTDEV_GRANT_COPY to allow applications to copy between user
>> space buffers and grant references.
>>
>> This interface is similar to the GNTTABOP_copy hypercall ABI except
>> the local buffers are provided using a virtual address (instead of a
>> GFN and offset).  To avoid userspace from having to page align its
>> buffers the driver will use two or more ops if required.
>>
>> If the ioctl returns 0, the application must check the status of each
>> segment with the segments status field.  If the ioctl returns a -ve
>> error code (EINVAL or EFAULT), the status of individual ops is
>> undefined.
> 
> Are there any test tools that could be used for this? To make sure that
> regression wise this does not get broken?

See attached.

>> +static int gntdev_copy(struct gntdev_copy_batch *batch)
>> +{
>> +unsigned int i;
>> +
>> +gnttab_batch_copy(batch->ops, batch->nr_ops);
>> +gntdev_put_pages(batch);
>> +
>> +/*
>> + * For each completed op, update the status if the op failed
>> + * and a previous failure for the segment hasn't been
>> + * recorded.
> 
> How could an previous failure not be recorded? Could you mention that
> in this nice comment please?

All the negatives in this sentence are confusing so I'll reword.

If we haven't recorded a failure for the previous op in the segment it's
because it succeeded.  The aim here is to record the first op failure
for a segment.  From the ioctl documentation:

+ * If the driver had to split a segment into two or more ops, @status
+ * includes the status of the first failed op for that segment (or
+ * GNTST_okay if all ops were successful).

>> +static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user 
>> *u)
>> +{
>> +struct ioctl_gntdev_grant_copy copy;
>> +struct gntdev_copy_batch batch = { .nr_ops = 0, .nr_pages = 0, };
>> +unsigned int i;
>> +int ret = 0;
>> +
>> +if (copy_from_user(©, u, sizeof(copy)))
>> +return -EFAULT;
>>
> +
> 
> No check on the .nr_pages' ? What if it is 0xf?
> 
> Ditto for .nr_ops?

batch.nr_ops and batch.nr_pages are internal, not supplied by the user
and are limited by the batch size.

I guess you're really asking about the value of copy.count?  This
doesn't matter because we process the segments one by one and have a
fixed batch size for the ops.

There's also a cond_resched() every segment so submitting a single ioctl
with a crazy number of segments is really no different from userspace
calling the ioctl a crazy number of times.

David

p.s. Please trim your replies when reviewing.
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

struct gntdev_grant_copy_segment {
	union {
		void *virt;
		struct {
			grant_ref_t ref;
			uint16_t offset;
			domid_t domid;
		} foreign;
	} source, dest;
	uint16_t len;

	uint16_t flags;  /* GNTCOPY_* */
	int16_t status; /* GNTST_* */
};

#define IOCTL_GNTDEV_GRANT_COPY \
	_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
struct ioctl_gntdev_grant_copy {
	unsigned int count;
	struct gntdev_grant_copy_segment *segments;
};

#define NR_REFS 15

static void random_fill(char *buf, size_t len)
{
int fd;
int r = 0;

fd = open("/dev/urandom", O_RDONLY);
if (fd < 0) {
perror("open(/dev/urandom)");
exit(1);
}

while (r < len) {
int ret;

ret = read(fd, buf + r, len - r);
if (ret < 0) {
perror("read");
exit(1);
}
r += ret;
}
close(fd);
}

static void do_copy(struct ioctl_gntdev_grant_copy *copy, char *a, char *b)
{
int fd;
unsigned int i;
int ret;

random_fill(a, NR_REFS * 4096);

fd = open("/dev/xen/gntdev", O_RDWR);
if (fd < 0) {
perror("open(/dev/xen/gntdev)");
exit(1);
}

ret = ioctl(fd, IOCTL_GNTDEV_GRANT_COPY, copy);
if (ret < 0) {
perror("ioctl(IOCTL_GNTDEV_GRANT_COPY)");
exit(1);
}

close(fd);

for (i = 0; i < NR_REFS; i++) {
if (copy->segments[i].status != GNTST_okay) {
fprintf(stderr, "[%u]: bad copy status: %d\n", i, copy->segments[i].status);
exit(1);
}
}

if (memcmp(a, b, NR_REFS * 4096) != 0) {
fprintf(stderr, "a != b\n");
exit(1);
}
}

int main(void)
{
xc_gntshr *gs;
xc_gnttab *gt;
uint32_t refs[NR_REFS];
struct gntdev_grant_copy_segment seg[NR_REFS];
struct ioctl_gntdev_grant_copy copy;
char *shared;
char local[4096 * NR_REFS];
unsigned int i;

gs = xc_gntshr_open(NULL, 0);
if (!gs) {
perror("xc_gntshr_open");
exit(1);
}

gt = xc_gnttab_open(NULL, 0);
if (!gt) {
perror("xc_gnttab_open");
exit(1);
}

shared = xc_gntshr_share_pages(gs, 0, NR_REFS, refs, 1);
if (shared == NUL

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Ian Campbell]

On Tue, 2015-12-01 at 10:33 +, Wei Liu wrote:
> 
> > > Just some thought after a quick look at the code. I will see what I
> > > can
> > > do after confirming this is the culprit.
> > 
> > I don't mind finishing this one off (although I'm also equally happy to
> > hand it over ;-))
> 
> Already working on a patch. :-)

OK, good thing I hadn't started on it yet then.

Ian.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Is there a way to get a VM base (starting) address?

[Ian Campbell]

On Mon, 2015-11-30 at 23:53 -0500, D'Mita Levy wrote:
> I am interested in locating a VM's base (starting) address in memory in
> relation to other VM's running on the same host - is there a way to do
> this through Xen or the XenAPI?

VM memory is not allocated contiguously in host memory, it can be scattered
from all over the place.

So there is no such thing as a "base address" in relation to other VM's.

Obviously a guest kernel has a starting address in the virtual/guest-
physical address space, but I don't think that is what you are asking for
(and in any case would be internal to the guest and not generally exposed
to toolstacks).

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Xen 4.7 Development Update

[Wei Liu]

This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.7 so that people have an idea what is going on and
prioritise accordingly.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming 4.7 timeline are as followed:

* Last posting date: March 18, 2016
* Hard code freeze: April 1, 2016
* RC1: TBD
* Release: June 3, 2016

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.7 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

= Projects =

== Hypervisor == 

=== x86 === 

*  xSplice, hypervisor hot-patching
  -  Konrad Wilk
  -  Ross Lagerwall

*  Porting Intel PState driver
  -  Wei Wang

*  HVM-nodm support
  -  Roger Pau Monne

*  Posted interrupt
  -  Wu, Feng

*  VMX TSC scaling support
  -  Haozhong Zhang

*  VT-d asynchronous flush issue
  -  Quan Xu

*  Memory protection-key support
  -  Huaitong Han

=== ARM === 

*  Guest save / restore support
  -  Ian Campbell

== Toolstack == 

*  Libxc support for migrating large PV domains
  -  Juergen Gross

*  Disentangle libxenctrl to stable libraries
  -  Ian Campbell

*  Libxl PVSCSI support
  -  Olaf Hering

*  PV USB passthrough
  -  Chunyan Liu

*  HVM USB passthrough
  -  George Dunlap

*  QEMU based PVUSB backend
  -  Juergen Gross

*  Domain snapshot API
  -  Chunyan Liu

*  Fix hotplug script machinery and remove blktap
  -  George Dunlap

*  Basic xSplice tooling (see hypervisor item)
  -  Konrad Wilk

*  Load BIOS via toolstack
  -  Anthony Perard

*  Libxl depriv QEMU
  -  Ian Jackson

*  COLO
  -  Yang Hongyang

== Documentation == 

*  Feature maturity lifecycle
  -  Lars Kurth

== Completed == 

*  vgic-v3
  -  Julien Grall

*  xsave/xrtors support
  -  Shuai Ruan

*  Toolstack-based soft reset
  -  Vitaly Kuznetsov

*  Libxc support for building large PV domains
  -  Juergen Gross

*  Run QEMU as non-root
  -  Stefano Stabellini

*  Intel CDP support
  -  He Chen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Emulating in response of an int3 vm_event

[Andrew Cooper]

On 01/12/15 01:21, Tamas K Lengyel wrote:
>
>
> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> On 12/01/2015 01:32 AM, Tamas K Lengyel wrote:
> > Hi all,
> > I'm trying to extend the current vm_event system to be able to
> emulate
> > over an in-guest breakpoint using the
> VM_EVENT_FLAG_SET_EMUL_READ_DATA
> > feature. The idea is to have the vm_event listener send back the
> > contents of the memory that was overwritten by the breakpoint
> > instruction, have Xen emulate one instruction, and resume execution
> > normally afterwards. This would eliminate the need of removing the
> > breakpoint, singlestepping, and placing the breakpoint back again.
> >
> > Unfortunately I encounter this crash when I call
> > hvm_mem_access_emulate_one in the event response handler:
> >
> > (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37
> > (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
>

This BUG() is the cause of the crash.

It is a bad parameter to VMREAD, by the looks of it.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option

[David Vrabel]

On 30/11/15 21:35, Doug Goldstein wrote:
> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
> and /dev/xen/xenbus via pvops is used instead. This is an effort to
> eventually drop this interface after a reasonable amount of time.

I would prefer the /proc/xen/xenbus and /proc/xen/evtchn files to be
replaced with symlinks to the corresponding /dev/xen/ devices.  Then I
see no need to ever remove them, thus avoiding the need for yet another
config option.

I did briefly look at this and it seemed possible but didn't get as far
as actually trying to change it.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option

[David Vrabel]

On 01/12/15 10:42, David Vrabel wrote:
> On 30/11/15 21:35, Doug Goldstein wrote:
>> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
>> and /dev/xen/xenbus via pvops is used instead. This is an effort to
>> eventually drop this interface after a reasonable amount of time.
> 
> I would prefer the ... /proc/xen/evtchn files to be

I meant /proc/xen/privcmd here.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Anshul Makkar]

Snabbswitch (virtualized switch) also encountered similar problem : 
https://groups.google.com/forum/#!topic/snabb-devel/xX0yFzeXylI

Thanks
Anshul Makkar

-Original Message-
From: Andrew Cooper [mailto:andrew.coop...@citrix.com] 
Sent: 01 December 2015 10:34
To: Konrad Rzeszutek Wilk 
Cc: Jan Beulich ; Kevin Tian ; 
yang.z.zh...@intel.com; Malcolm Crossley ; Anshul 
Makkar ; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for 
Sandybridge and earlier processors.

On 30/11/15 21:22, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 26, 2015 at 01:55:57PM +, Andrew Cooper wrote:
>> On 26/11/15 13:48, Malcolm Crossley wrote:
>>> On 26/11/15 13:46, Jan Beulich wrote:
>>> On 25.11.15 at 11:28,  wrote:
> The problem is that SandyBridge IOMMUs advertise 2M support and do 
> function with it, but cannot cache 2MB translations in the IOTLBs.
>
> As a result, attempting to use 2M translations causes 
> substantially worse performance than 4K translations.
 Btw - how does this get explained? At a first glance, even if 2Mb 
 translations don't get entered into the TLB, it should still be one 
 less page table level to walk for the IOMMU, and should hence 
 nevertheless be a benefit. Yet you even say _substantially_ worse 
 performance results.
>>> There is a IOTLB for the 4K translation so if you only use 4K 
>>> translations then you get to take advantage of the IOTLB.
>>>
>>> If you use the 2Mb translation then a page table walk has to be 
>>> performed every time there's a DMA access to that region of the BFN 
>>> address space.
>> Also remember that a high level dma access (from the point of view of 
>> a
>> driver) will be fragmented at the PCIe max packet size, which is 
>> typically 256 bytes.
>>
>> So by not caching the 2Mb translation, a dma access of 4k may undergo 
>> 16 pagetable walks, one for each PCIe packet.
>>
>> We observed that using 2Mb mappings results in a 40% overhead, 
>> compared to using 4k mappings, from the point of view of a sample network 
>> workload.
> How did you observe this? I am mighty curious what kind of performance 
> tools you used to find this  as I would love to figure out if some of 
> the issues we have seen are related to this?

The 40% difference is just in terms of network throughput of a VF, given a 
workload which can normally saturate line rate on the card.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Juergen Gross]

On 01/12/15 11:01, Ian Campbell wrote:
> On Tue, 2015-12-01 at 09:53 +0100, Juergen Gross wrote:
>> On 01/12/15 09:30, Ian Campbell wrote:
>>> On Tue, 2015-12-01 at 08:41 +0100, Juergen Gross wrote:
>> I'm not quite sure what to make of this, in particular I don't
>> see
 anything
>> in kexec.c which obviously looks after unmapping the heap or brk
 areas.
>
> Nah, this backtrace shows a normal allocation path while
> uncompressing the kernel image. I'd expect something like that.
> Why shouldn't mini-os make use of pfn 4d81 somewhere?
>>>
>>> That pfn ends up right in the middle of the next-kernels vaddr mapping,
>>> so at best it indicates some sort of disconnect/overlap between the
>>> mini-os memory allocator and the domain-builder memory allocator.
>>
>> I don't think so.
>>
>> mini-os just allocates single pages and keeps the relation to the
>> (future) pfn of that page. The p2m list is adjusted later to move the
>> allocated page to that pfn before activating the new kernel.
> 
> Ah, I was wondering how it could possibly work so I half expected I must be
> missing something.
> 
>>> Since it seems to be in the middle of the padding area (which might
>>> have been new in ea7c8a3d0e82, I'm not sure, it seems to be more
>>> explicit at the least) it occurred to me on the way home last night
>>> that maybe we need to unmap the padding area as well.
>>
>> We do. The page tables need to be unmapped independently as they
>> have been mapped explicitly during setup_pgtables(dom). All the
>> mini-os mappings are removed in a loop just after that.
> 
> "a loop" is this:
> /* Unmap day0 pages to avoid having a r/w mapping of the future page 
> table */
>for (pfn = 0; pfn < allocated; pfn++)
> munmap((void*) pages[pfn], PAGE_SIZE);
> 
> In my debugging this extends only to the end of the actual mappings, not to
> the end of the padding, e.g. for me it is extending to "Unmap pfns 0 ..
> 0x4c0f" while the unexpected PT pfn is at 0x4d80 and the padding area
> extends to pfn 0x5000.
> 
>>> I'll try that and your suggested patch below as well once I get to the
>>> office this morning.
>>
>> Thanks.
> 
> The BUG_ON doesn't seem to be triggering. I'm not seeing pfn==0x4d80 going
> anywhere near kexec_allocate, the highest is 0x4c0f.
> 
> Maybe the issue is that the ->allocate hook (==kexec_allocate) isn't called
> from xc_dom_alloc_pad?

OMG! How could I miss that? Thanks for finding this!


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Emulating in response of an int3 vm_event

[Andrew Cooper]

On 01/12/15 10:40, Andrew Cooper wrote:
> On 01/12/15 01:21, Tamas K Lengyel wrote:
>>
>>
>> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru
>> mailto:rcojoc...@bitdefender.com>> wrote:
>>
>> On 12/01/2015 01:32 AM, Tamas K Lengyel wrote:
>> > Hi all,
>> > I'm trying to extend the current vm_event system to be able to
>> emulate
>> > over an in-guest breakpoint using the
>> VM_EVENT_FLAG_SET_EMUL_READ_DATA
>> > feature. The idea is to have the vm_event listener send back the
>> > contents of the memory that was overwritten by the breakpoint
>> > instruction, have Xen emulate one instruction, and resume execution
>> > normally afterwards. This would eliminate the need of removing the
>> > breakpoint, singlestepping, and placing the breakpoint back again.
>> >
>> > Unfortunately I encounter this crash when I call
>> > hvm_mem_access_emulate_one in the event response handler:
>> >
>> > (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37
>> > (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
>>
>
> This BUG() is the cause of the crash.
>
> It is a bad parameter to VMREAD, by the looks of it.

Jan: This is a good example of why unlikely regions should have
symbols.  The stack trace from this bug is actively misleading because
the symbol information for %eip is wrong.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv6] 01/28] build: import Kbuild/Kconfig from Linux 4.2

[Jan Beulich]

>>> On 30.11.15 at 18:16,  wrote:
> Jan Beulich writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from 
> Linux 4.2"):
>> On 30.11.15 at 16:42,  wrote:
>> > I would go further than this, and wholesale import the relevant files
>> > into a subdirectory in a single commit that contains nothing else, and
>> > mention the specific git commit id and version number in the Linux
>> > tree in the commit message.
>> 
>> But what's the point of importing things we're not going to use?
> 
> I thought I had explained that.
> 
> A future re-import or merge will be much simpler if this import is a
> simple wholesale copy of a directory or two or a simple glob pattern.
> 
> The runes used to do the import could be in the commit message for
> easy reproduction.
> 
>> Imo such an import should be limited to those files that (later on)
>> would actually get wired up. Hence the request to do a minimalistic
>> import for this first round.
> 
> This would involve a series of piece-by-piece imports.  Any future
> merge or re-import would involve retracing and re-executing those
> steps.
> 
> It appears that we do disagree.  Perhaps the basic thing is: I don't
> think we want to fork this code.  We want to be a downstream of Linux
> for it.  If necessary we may edit, to an extent, the parts we import,
> but hopefully we'll keep that to a minimum.

But not forking doesn't mean importing the whole directory. Some
Makefile adjustments will be necessary anyway, so removing some
of the frontends wouldn't make things worse. We indeed should
avoid editing files we import, but I don't see any bad in skipping
some of the files.

Reasons I'd like to avoid importing everything:
- no introduction of new build dependencies (one of the frontends
being written in C++ is the mildest form, requiring HOSTCXX to be
set),
- limiting the amount of new code that needs maintaining (no
matter how simple a re-import, it still is work, and hence the less
frequently we need to do this, the better; I assume you agree
that the likelihood for changes that we want/need to pull in
grows with the size of the code, and with what I propose the
import size would shrink by almost 50%), unless you or Doug
volunteer to look after this code on a regular basis,
- avoiding code (scripts) that seem completely pointless in our
environment (e.g. streamline_config.pl).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv6] 01/28] build: import Kbuild/Kconfig from Linux 4.2

[Jan Beulich]

>>> On 30.11.15 at 18:00,  wrote:
> So you want me to break this patch up to bring in the frontends
> individually? Since there is a request to have KEXEC and the UARTs
> configurable by the user I would bring in all these frontends.

No, I want them to be left out entirely. But it looks like we first need
to settle on what we actually (don't) want.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] dom builder logging from pvgrub.

[Ian Campbell]

I found the following hack quite handy here. Posting it for the
archives/posterity, I don't really plan to clean it up and submit it
properly (since I'm not really sure what a non-hack version would be).

In case anyone wants to pick it up:
Signed-off-by: Ian Campbell 

(lightly edited in patch form to remove some of the worst bodging)


diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 8fd9ff9..761ca7f 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -209,6 +209,35 @@ static void tpm_hash2pcr(struct xc_dom_image *dom, char 
*cmdline)
    shutdown_tpmfront(tpm);
 }
 
+static void builder_vmessage(struct xentoollog_logger *logger,
+ xentoollog_level level,
+ int errnoval,
+ const char *context,
+ const char *format,
+ va_list ap)
+{
+  char buf[1024];
+
+  vsnprintf(buf, sizeof(buf), format, ap);
+
+  printk("%s%s%s\n",
+     context ? : "",
+     context ? ": " : "",
+     buf);
+}
+static void builder_progress(struct xentoollog_logger *logger,
+ const char *context,
+ const char *doing_what,
+ int percent, unsigned long done, unsigned long total)
+{
+  printk("%s\n", __func__);
+}
+
+static void builder_destroy(struct xentoollog_logger *logger)
+{
+  printk("%s\n", __func__);
+}
+
 void kexec(void *kernel, long kernel_size, void *module, long module_size, 
char *cmdline, unsigned long flags)
 {
 struct xc_dom_image *dom;
@@ -223,8 +253,14 @@ void kexec(void *kernel, long kernel_size, void *module, 
long module_size, char
 struct mmu_update *m2p_updates;
 unsigned long nr_m2p_updates;
 
+struct xentoollog_logger lg = {
+   .vmessage = builder_vmessage,
+   .progress = builder_progress,
+   .destroy = builder_destroy,
+};
+
 DEBUG("booting with cmdline %s\n", cmdline);
-xc_handle = xc_interface_open(0,0,0);
+xc_handle = xc_interface_open(0,&lg,&lg);
 
 dom = xc_dom_allocate(xc_handle, cmdline, features);
 dom->allocate = kexec_allocate;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 30.11.15 at 18:53,  wrote:
> On 11/30/15 8:36 AM, Jan Beulich wrote:
> On 24.11.15 at 18:51,  wrote:
>>> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
>>> +
>>> +config SRCARCH
>>> +   string
>>> +   option env="SRCARCH"
>>> +
>>> +config ARCH
>>> +   string
>>> +   option env="ARCH"
>>> +
>>> +source "arch/$SRCARCH/Kconfig"
>>> +
>>> +config XEN_FULLVERSION
>>> +   string
>>> +   option env="XEN_FULLVERSION"
>>> +
>>> +config DEFCONFIG_LIST
>>> +   string
>>> +   option defconfig_list
>>> +   default "$ARCH_DEFCONFIG"
>>> +   default "arch/$SRCARCH/defconfig"
>> 
>> Linux'es variant has just SRCARCH and the source directive. Why
>> do we need so much more here? In any even I again think you
>> should at least briefly explain any extensions you do in the commit
>> message.
> 
> I'm not understanding the question here. Linux has 5 items in their
> list. The last two are identical to the 2 that I retained. Given other
> evolutions of the patchset I can drop the last one and keep it as just
> $ARCH_DEFCONFIG since I've always got that defined for arm and x86.

Oh, the context was ambiguous: The comment related to everything
quoted, not just the last option. I.e. I'm being irritated by there being
quite a few more config options here compared to Linux.

>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>>>  
>>>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>>>  
>>> +# Don't break if the build process wasn't called from the top level
>>> +XEN_TARGET_ARCH ?= $(shell uname -m)
>> 
>> I don't see the need for this. We already require setting this on the
>> command line when invoking a build process bypassing the top level
>> directory. Later in the series, when actually using the produced
>> xen/.config, I could see this becoming a nice enhancement (by
>> reading the value from the file).
> 
> One of the early on reviews told me it was not required (and I can
> confirm that I can run "git clean -xdf && cd xen && make" and it will
> build). This change makes that behavior still work.

Yes, non-cross builds of course have been working without setting
that variable. I was (not clearly enough) referring to cross builds,
including hypervisor builds on ix86 distros (which I consider at best
kind of cross, but would really deem to be native with there not
being any 32-bit hypervisor anymore).

So can you clarify what exactly breaks in which way without this
change?

>>> @@ -216,3 +220,16 @@ FORCE:
>>>  
>>>  %/: FORCE
>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
>>> +
>>> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
>>> +   nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
>>> +.PHONY: $(kconfig)
>>> +$(kconfig):
>>> +   $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
>>> $@
>>> +
>>> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
>>> +   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>>> ARCH=$(XEN_TARGET_ARCH) silentoldconfig
>> 
>> Okay, I have found the Linux original to this and it's the same there,
>> but I'd like to ask anyway: How can this work without $* getting
>> passed on?
> 
> silentoldconfig is the step that actually takes the .config and
> generates out all the files like auto.conf and generated/config.h It
> should be in xen/scripts/kconfig/Makefile.linux I believe.

Not sure what you're trying to tell me, but in any event I don't see
this to answer the question.

>>> +# Allow people to just run `make` as before and not force them to configure
>>> +$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
>>> +   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>>> ARCH=$(XEN_TARGET_ARCH) defconfig
>> 
>> Is this correct? If I have xen/.config but no
>> xen/include/config/auto.conf.cmd I surely don't want "defconfig" to
>> be run (unless "defconfig" honors xen/.config, in which case the
>> goal's name would be questionable)?
>> 
>> Also do you really need all the explicit $(BASEDIR) references in the
>> rules above?
> 
> I was asked to make the build work with out of tree builds and that's
> why I went this route. The rest of the Xen build system doesn't support
> out of tree builds so one can argue that's not needed.

That can't be right - $(BASEDIR) can't possibly refer to both the
source and object trees, yet the code above clearly references
both.

>>> --- /dev/null
>>> +++ b/xen/arch/arm/configs/arm32_defconfig
>>> @@ -0,0 +1 @@
>>> +CONFIG_64BIT=n
>>> diff --git a/xen/arch/arm/configs/arm64_defconfig 
>>> b/xen/arch/arm/configs/arm64_defconfig
>>> new file mode 100644
>>> index 000..e69de29
>> 
>> As said before I'm not really up to speed with defconfigs, but the
>> arm64 variant being empty but the arm32 one disabling 64BIT
>> seems backwards: You don't even have a choice on arm32.
> 
> I agree its squirrelly here. I believe I followed Linux and it only
> seems to come into play when you don't specify you'r

Re: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT

[Paul Durrant]

> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Don Slutz
> Sent: 28 November 2015 21:45
> To: xen-devel@lists.xen.org
> Cc: Jun Nakajima; Wei Liu; Kevin Tian; Keir (Xen.org); Ian Campbell; George
> Dunlap; Andrew Cooper; Stefano Stabellini; Eddie Dong; Don Slutz; Don Slutz;
> Tim (Xen.org); Aravind Gopalakrishnan; Jan Beulich; Suravee Suthikulpanit;
> Boris Ostrovsky; Ian Jackson
> Subject: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT
> 
> From: Don Slutz 
> 
> This adds synchronization of the 6 vcpu registers (only 32bits of
> them) that vmport.c needs between Xen and QEMU.
> 
> This is to avoid a 2nd and 3rd exchange between QEMU and Xen to
> fetch and put these 6 vcpu registers used by the code in vmport.c
> and vmmouse.c
> 
> In the tools, enable usage of QEMU's vmport code.
> 
> The currently most useful VMware port support that QEMU has is the
> VMware mouse support.  Xorg included a VMware mouse support that
> uses absolute mode.  This make using a mouse in X11 much nicer.
> 
> Signed-off-by: Don Slutz 
> Acked-by: Ian Campbell 
> CC: Don Slutz 
> ---
> v13:
>   Rebased on staging (not a simple rebase, needed rework to function
>   with changes).
> I would have made this !vmport_check_port ...
>Changed to !is_vmware, and invert vmport_check_port's return value.
>   Use 1 one for "list_for_each_entry ( sv, ..."
>   Added full stop in comments.
> 
> v12:
>   Rebase changes.
> 
>   Pass size to vmport_check_port() -- required if overlap
>   I.E. inl on port 0x5657, 0x5656, 0x5655, 0x5659, 0x565a,
>   and 0x565b.
> 
>   Move define of vmport_check_port() into this patch from ring3
>   patch.
> 
> v11:
>   No change
> 
> v10:
>   These literals should become an enum.
> I don't think the invalidate type is needed.
> Code handling "case X86EMUL_UNHANDLEABLE:" in emulate.c
> is unclear.
> Comment about "special' range of 1" is not clear.
> 
> 
> v9:
>   New code was presented as an RFC before this.
> 
>   Paul Durrant sugested I add support for other IOREQ types
>   to HVMOP_map_io_range_to_ioreq_server.
> I have done this.
> 
>  tools/libxc/xc_dom_x86.c |   5 +-
>  tools/libxl/libxl_dm.c   |   2 +
>  xen/arch/x86/hvm/emulate.c   |  68 +++---
>  xen/arch/x86/hvm/hvm.c   | 194
> ++-
>  xen/arch/x86/hvm/vmware/vmport.c |  14 +++
>  xen/include/asm-x86/hvm/domain.h |   3 +-
>  xen/include/asm-x86/hvm/hvm.h|   2 +
>  xen/include/public/hvm/hvm_op.h  |   5 +
>  xen/include/public/hvm/ioreq.h   |  17 
>  xen/include/public/hvm/params.h  |   4 +-
>  10 files changed, 275 insertions(+), 39 deletions(-)
> 
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index 5ff33ca..4c8a7fe 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -60,7 +60,8 @@
>  #define SPECIALPAGE_IOREQ5
>  #define SPECIALPAGE_IDENT_PT 6
>  #define SPECIALPAGE_CONSOLE  7
> -#define NR_SPECIAL_PAGES 8
> +#define SPECIALPAGE_VMPORT_REGS 8
> +#define NR_SPECIAL_PAGES 9
>  #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
> 
>  #define NR_IOREQ_SERVER_PAGES 8
> @@ -613,6 +614,8 @@ static int alloc_magic_pages_hvm(struct
> xc_dom_image *dom)
>   special_pfn(SPECIALPAGE_BUFIOREQ));
>  xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_PFN,
>   special_pfn(SPECIALPAGE_IOREQ));
> +xc_hvm_param_set(xch, domid, HVM_PARAM_VMPORT_REGS_PFN,
> + special_pfn(SPECIALPAGE_VMPORT_REGS));
>  xc_hvm_param_set(xch, domid, HVM_PARAM_CONSOLE_PFN,
>   special_pfn(SPECIALPAGE_CONSOLE));
>  xc_hvm_param_set(xch, domid, HVM_PARAM_PAGING_RING_PFN,
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index c76fd90..50e6d93 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1150,6 +1150,8 @@ static int
> libxl__build_device_model_args_new(libxl__gc *gc,
>  }
>  }
> 
> +if (libxl_defbool_val(c_info->vmware_port))
> +machinearg = GCSPRINTF("%s,vmport=on", machinearg);
>  flexarray_append(dm_args, machinearg);
>  for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
>  flexarray_append(dm_args, b_info->extra_hvm[i]);
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index e1017b5..d407741 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -113,6 +113,7 @@ static int hvmemul_do_io(
>  };
>  void *p_data = (void *)data;
>  int rc;
> +bool_t is_vmware = !is_mmio && !data_is_addr &&
> vmport_check_port(p.addr, p.size);
> 
>  /*
>   * Weird-sized accesses have undefined behaviour: we discard writes
> @@ -133,7 +134,7 @@ static int hvmemul_do_io(
>  p = vio->io_req;
> 
>  /* Verify the emulation request has been correctly re-is

[Xen-devel] [PATCH] public/sysctl: Clarifications to XEN_SYSCTL_PHYSCAP_hvm_directio

[Andrew Cooper]

Specifically that it indicates passthrough support for PV guests as well

Signed-off-by: Andrew Cooper 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Ian Campbell 
CC: Ian Jackson 
---
 xen/include/public/sysctl.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 96680eb..cbbeecd 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -89,7 +89,14 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_tbuf_op_t);
  /* (x86) The platform supports HVM guests. */
 #define _XEN_SYSCTL_PHYSCAP_hvm  0
 #define XEN_SYSCTL_PHYSCAP_hvm   (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
- /* (x86) The platform supports HVM-guest direct access to I/O devices. */
+ /*
+  * (x86) The platform supports guest direct access to I/O devices.
+  *
+  * Note that this parameter has been misnamed since its introduction, and is
+  * now too baked into APIs and ABIs to change.  Despite the "hvm" in its
+  * name, it simply indicates the presence of an enabled IOMMU, allowing for
+  * passthrough of devices to guests, including PV guests.
+  */
 #define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
 #define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
 struct xen_sysctl_physinfo {
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] boot xen use legacy bios

[Jan Beulich]

>>> On 01.12.15 at 01:02,  wrote:
> Sorry,  I thought they are due to same reason so I put them together. Maybe I 
> should just solve them one by one. Full log is here  
> paste.ubuntu.com/13571815/, if you need more information, please let me know.

I'm not sure what this (truncated at the beginning) log is supposed
to be demonstrating.

Can you please start new threads for all of the issues you currently
have, properly distinguishing between ones that should go here vs
onto xen-users?

Jan

>> Date: Mon, 30 Nov 2015 08:50:42 -0700
>> From: jbeul...@suse.com 
>> To: quizy_jo...@outlook.com 
>> CC: xen-devel@lists.xen.org 
>> Subject: Re: [Xen-devel] boot xen use legacy bios
>> 
> On 30.11.15 at 16:36,  wrote:
>> 
>> First of all - please no HTML mails, just plain text.
>> 
>>> Thanks for your reply. I've already changed to boot with the xen.efi 
> directly 
>>> without grub2. Now I can see all the cpu cores, but I can't use the mouse 
>>> or 
> 
>>> keyboard. What's more, the memory seems to be problematic too. 'xl dmesg' 
>>> shows :
>>> (XEN) Unknown cachability for MFNs 0x8-0x8(XEN) Unknown cachability 
>>> for MFNs 0xfeda8-0xfedab(XEN) Initial low memory virq threshold set at 
>>> 0x4000 
> 
>>> pages.
>> 
>> None of this can be analyzed without full logs.
>> 
>>>(XEN) HVM1 restore: bad CR4 0x1526f0(XEN) HVM1 restore: failed to load 
>>> entry 2/0(d4) Relocating guest memory for lowmem MMIO space disabled(d4) No 
>>> RAM in high memory; setting high_mem resource base to 1
>>> Even though finally the domain 4 booted, using libxc api 
>>> xc_domain_maximum_gpfn(xen->xchandle, xen->domainid) cannot get the 
>>> max_gpfn. 
>> 
>> And please don't merge multiple completely different issues in a
>> single thread (and for those secondary issues under a completely
>> misleading title).
>> 
>> Jan
>> 
>> 
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Wei Liu]

There were some problems with the original memory allocation functions:
1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
   xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
2. xc_dom_alloc_pad didn't call dom->allocate.

Refactor the code so that:
1. xc_dom_alloc_{segment,pad,page} end up calling
   xc_dom_chk_alloc_pages.
2. xc_dom_chk_alloc_pages calls dom->allocate.

This way we avoid scattering dom->allocate over multiple locations and
open-coding.

Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
an invalid pfn when xc_dom_chk_alloc_pages fails.

Signed-off-by: Wei Liu 
---
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Juergen Gross 

We don't have INVALID_PFN, maybe we need one?

Tested with Jessie with 64 bit pvgrub, Wheezy with 64 bit pvgrub, Wheezy pv
guest, Wheezy HVM guest, Wheezy HVM with qemu stubdom.

 tools/libxc/include/xc_dom.h |  2 +-
 tools/libxc/xc_dom_core.c| 16 +++-
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 2176216..2d0de8c 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -350,7 +350,7 @@ char *xc_dom_strdup(struct xc_dom_image *dom, const char 
*str);
 
 /* --- alloc memory pool --- */
 
-int xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
+xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
 int xc_dom_alloc_segment(struct xc_dom_image *dom,
  struct xc_dom_seg *seg, char *name,
  xen_vaddr_t start, xen_vaddr_t size);
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 5d6c3ba..8967970 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -555,6 +555,9 @@ static int xc_dom_chk_alloc_pages(struct xc_dom_image *dom, 
char *name,
 dom->pfn_alloc_end += pages;
 dom->virt_alloc_end += pages * page_size;
 
+if ( dom->allocate )
+dom->allocate(dom);
+
 return 0;
 }
 
@@ -602,9 +605,6 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
 if ( xc_dom_chk_alloc_pages(dom, name, pages) )
 return -1;
 
-if (dom->allocate)
-dom->allocate(dom);
-
 /* map and clear pages */
 ptr = xc_dom_seg_to_ptr(dom, seg);
 if ( ptr == NULL )
@@ -621,18 +621,16 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
 return 0;
 }
 
-int xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
+xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
 {
-unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
 xen_vaddr_t start;
 xen_pfn_t pfn;
 
 start = dom->virt_alloc_end;
 pfn = dom->pfn_alloc_end - dom->rambase_pfn;
-dom->virt_alloc_end += page_size;
-dom->pfn_alloc_end++;
-if ( dom->allocate )
-dom->allocate(dom);
+
+if ( xc_dom_chk_alloc_pages(dom, name, 1) )
+return (xen_pfn_t)-1;
 
 DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " (pfn 0x%" PRIpfn ")",
   __FUNCTION__, name, start, pfn);
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Juergen Gross]

On 01/12/15 12:39, Wei Liu wrote:
> There were some problems with the original memory allocation functions:
> 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
>xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
> 2. xc_dom_alloc_pad didn't call dom->allocate.
> 
> Refactor the code so that:
> 1. xc_dom_alloc_{segment,pad,page} end up calling
>xc_dom_chk_alloc_pages.
> 2. xc_dom_chk_alloc_pages calls dom->allocate.
> 
> This way we avoid scattering dom->allocate over multiple locations and
> open-coding.
> 
> Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
> an invalid pfn when xc_dom_chk_alloc_pages fails.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Juergen Gross 

> ---
> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Juergen Gross 
> 
> We don't have INVALID_PFN, maybe we need one?
> 
> Tested with Jessie with 64 bit pvgrub, Wheezy with 64 bit pvgrub, Wheezy pv
> guest, Wheezy HVM guest, Wheezy HVM with qemu stubdom.
> 
>  tools/libxc/include/xc_dom.h |  2 +-
>  tools/libxc/xc_dom_core.c| 16 +++-
>  2 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 2176216..2d0de8c 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -350,7 +350,7 @@ char *xc_dom_strdup(struct xc_dom_image *dom, const char 
> *str);
>  
>  /* --- alloc memory pool --- */
>  
> -int xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
> +xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
>  int xc_dom_alloc_segment(struct xc_dom_image *dom,
>   struct xc_dom_seg *seg, char *name,
>   xen_vaddr_t start, xen_vaddr_t size);
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index 5d6c3ba..8967970 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -555,6 +555,9 @@ static int xc_dom_chk_alloc_pages(struct xc_dom_image 
> *dom, char *name,
>  dom->pfn_alloc_end += pages;
>  dom->virt_alloc_end += pages * page_size;
>  
> +if ( dom->allocate )
> +dom->allocate(dom);
> +
>  return 0;
>  }
>  
> @@ -602,9 +605,6 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
>  if ( xc_dom_chk_alloc_pages(dom, name, pages) )
>  return -1;
>  
> -if (dom->allocate)
> -dom->allocate(dom);
> -
>  /* map and clear pages */
>  ptr = xc_dom_seg_to_ptr(dom, seg);
>  if ( ptr == NULL )
> @@ -621,18 +621,16 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
>  return 0;
>  }
>  
> -int xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
> +xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
>  {
> -unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
>  xen_vaddr_t start;
>  xen_pfn_t pfn;
>  
>  start = dom->virt_alloc_end;
>  pfn = dom->pfn_alloc_end - dom->rambase_pfn;
> -dom->virt_alloc_end += page_size;
> -dom->pfn_alloc_end++;
> -if ( dom->allocate )
> -dom->allocate(dom);
> +
> +if ( xc_dom_chk_alloc_pages(dom, name, 1) )
> +return (xen_pfn_t)-1;
>  
>  DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " (pfn 0x%" PRIpfn ")",
>__FUNCTION__, name, start, pfn);
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv2] 1/3] libxc: prefer using privcmd character device

[Ian Campbell]

On Tue, 2015-11-24 at 14:14 -0600, Doug Goldstein wrote:
> Prefer using the character device over the proc file if the character
> device exists. This follows similar conversions of xenbus to avoid
> issues with FMODE_ATOMIC_POS added in Linux 3.14 and newer.
> 
> CC: Ian Jackson 
> CC: Stefano Stabellini 
> CC: Ian Campbell 
> CC: Wei Liu 
> Signed-off-by: Doug Goldstein 
> ---
>  tools/libxc/xc_linux_osdep.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
> index 76c55ff..c078b3d 100644
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -46,7 +46,14 @@
>  static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
>  {
>  int flags, saved_errno;
> -int fd = open("/proc/xen/privcmd", O_RDWR);
> +int fd = open("/dev/xen/privcmd", O_RDWR); /* prefer this newer
> interface */
> +
> +if ( fd == -1 && ( errno == ENOENT || errno == ENXIO ||
> +   errno == ENODEV || errno == EACCES ))

This adds EACCESS to the set Ian suggested would be tolerable in his reply
to v1. I'm leaning towards thinking that if the device is present but not
openable by the current user then that's a system configuration error which
should be reported.

Anyone want to argue otherwise?

> +{
> +/* Fallback to /proc/xen/privcmd */
> +fd = open("/proc/xen/privcmd", O_RDWR);
> +}
>  
>  if ( fd == -1 )
>  {

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 9p file system for xen

[Wei Liu]

On Mon, Nov 30, 2015 at 12:19:18PM -0500, Neil Sikka wrote:
> Hi Wei, could you please explain why/how you would have done the project
> differently now and why these patches are not "good"? From my conversation
> with Linda, I understood that her code is "Independent of virtio except the
> 9pvirtio specific code, which is used extensively."
> 

I need to implement a xen transport for 9pfs. Linda was essentially
doing the same. But she didn't specify the canonical protocol between
frontend and backend.

As for "9pvirtio specific code", I think there is misunderstanding
because though a lot of files in QEMU are prefixed with virtio they are
actually not specific to virtio at all. I think the "independent of
virtio ..." part was referring to the new transport she wrote.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 4/6] xl: Return an error on failed cd-insert

[George Dunlap]

This makes xl more useful in scripts.

The strange thing about this is that the internal cd_insert function
*already* returned something appropriate, and cd-eject was using it,
but cd-insert wasnt.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 4455d73..72ece2e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3405,8 +3405,7 @@ int main_cd_insert(int argc, char **argv)
 virtdev = argv[optind + 1];
 file = argv[optind + 2];
 
-cd_insert(domid, virtdev, file);
-return 0;
+return cd_insert(domid, virtdev, file);
 }
 
 int main_console(int argc, char **argv)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 6/6] xl: Return error code on save

[George Dunlap]

save_domain was already constructing an error code; it just wasn't
being used.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5f21c37..52aedcf 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4712,8 +4712,7 @@ int main_save(int argc, char **argv)
 if ( argc - optind >= 3 )
 config_filename = argv[optind + 2];
 
-save_domain(domid, filename, checkpoint, leavepaused, config_filename);
-return 0;
+return save_domain(domid, filename, checkpoint, leavepaused, 
config_filename);
 }
 
 int main_migrate(int argc, char **argv)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 1/6] xl: Return proper error codes for block-attach and block-detach

[George Dunlap]

Return proper error codes on failure so that scripts can tell whether
the command completed properly or not.

Also while we're at it, normalize init and dispose of
libxl_device_disk structures.  This means calling init and dispose in
the actual functions where they are declared.

This in turn means changing parse_disk_config_multistring() to not
call libxl_device_disk_init.  And that in turn means changes to
callers of parse_disk_config().

It also means removing libxl_device_disk_init() from
libxl.c:libxl_vdev_to_device_disk().  This is only called from
xl_cmdimpl.c.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Konrad Wilk 

v3:
 - Rebased to tip

v2:
 - Restructure functions to make sure init and dispose are properly
 called.
---
 tools/libxl/libxl.c  |  2 --
 tools/libxl/xl_cmdimpl.c | 29 -
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bd3aac8..814d056 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2738,8 +2738,6 @@ int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t 
domid,
 if (devid < 0)
 return ERROR_INVAL;
 
-libxl_device_disk_init(disk);
-
 dompath = libxl__xs_get_dompath(gc, domid);
 if (!dompath) {
 goto out;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2b6371d..2ba2393 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -570,8 +570,6 @@ static void parse_disk_config_multistring(XLU_Config 
**config,
 {
 int e;
 
-libxl_device_disk_init(disk);
-
 if (!*config) {
 *config = xlu_cfg_init(stderr, "command line");
 if (!*config) { perror("xlu_cfg_init"); exit(-1); }
@@ -3340,6 +3338,8 @@ static int cd_insert(uint32_t domid, const char *virtdev, 
char *phys)
 xasprintf(&buf, "vdev=%s,access=r,devtype=cdrom,target=%s",
   virtdev, phys ? phys : "");
 
+libxl_device_disk_init(&disk);
+
 parse_disk_config(&config, buf, &disk);
 
 /* ATM the existence of the backing file is not checked for qdisk
@@ -6649,6 +6649,7 @@ int main_blockattach(int argc, char **argv)
 uint32_t fe_domid;
 libxl_device_disk disk;
 XLU_Config *config = 0;
+int rc = 0;
 
 SWITCH_FOREACH_OPT(opt, "", NULL, "block-attach", 2) {
 /* No options */
@@ -6660,6 +6661,8 @@ int main_blockattach(int argc, char **argv)
 }
 optind++;
 
+libxl_device_disk_init(&disk);
+
 parse_disk_config_multistring
 (&config, argc-optind, (const char* const*)argv + optind, &disk);
 
@@ -6668,14 +6671,17 @@ int main_blockattach(int argc, char **argv)
 printf("disk: %s\n", json);
 free(json);
 if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
-return 0;
+goto out;
 }
 
 if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
 fprintf(stderr, "libxl_device_disk_add failed.\n");
-return 1;
+rc = 1;
 }
-return 0;
+out:
+libxl_device_disk_dispose(&disk);
+
+return rc;
 }
 
 int main_blocklist(int argc, char **argv)
@@ -6726,18 +6732,23 @@ int main_blockdetach(int argc, char **argv)
 /* No options */
 }
 
+libxl_device_disk_init(&disk);
+
 domid = find_domain(argv[optind]);
 
 if (libxl_vdev_to_device_disk(ctx, domid, argv[optind+1], &disk)) {
 fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
-return 1;
+rc = 1;
+goto out;
 }
-rc = libxl_device_disk_remove(ctx, domid, &disk, 0);
-if (rc) {
+if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
 fprintf(stderr, "libxl_device_disk_remove failed.\n");
-return 1;
+rc = 1;
 }
+
+out:
 libxl_device_disk_dispose(&disk);
+
 return rc;
 }
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7 Development Update

[Lars Kurth]

Wei,
and others.

> On 25 Nov 2015, at 02:17, Han, Huaitong  wrote:
>> 
>> = Projects =
> 
> == Hypervisor ==
> === x86 ===
> *Memory protection keys for user pages
> -Huaitong Han

one thing I struggle with (and I am probably not the only one), is that it is 
not always easy do find out what a specific patch does in the Development 
Update mails. Obviously this is not an issue at the beginning of the cycle, but 
it can become one when we start to put the release notes and PR together. In 
this particular case, the use-case for the feature was described as a one-liner 
else-where and I am wondering, whether we should allow tracking the 
use/use-case/... in these mails.

Aka, in this case, using the information from the thread where the use-case was 
discussed, will give us something like ...  

== Hypervisor ==
=== x86 ===
* Memory protection keys for user pages
  (allows threads to cooperatively prevent themselves from "trampling" on each 
other, which increases robustness and is useful for debugging)
- Huaitong Han

Part of the reason, why I am also looking at this, is because of the Feature 
Lifecycle Management (see http://xen.markmail.org/message/uu3vifjmv2qylds4), 
where we still have outstanding issues on documenting completed features. It 
seems to me that there is an overlap between the Development Update mails, and 
recording the state of an added feature in a central file. Obviously, if a new 
feature was committed to xen.git, we would then need to add an entry to the 
still to be defined central file describing it. And it would probably make 
sense to keep the info in Development Update mails as close as possible to what 
is in the still to be defined file.

Any thoughts?

Cheers
Lars 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 3/6] xl: Make set_memory_target return an error code on failure

[George Dunlap]

Bring set_memory_target into line with set_memory_max (which does
return an error code.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Konrad Wilk 
---
 tools/libxl/xl_cmdimpl.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2ba2393..4455d73 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3297,9 +3297,10 @@ int main_memmax(int argc, char **argv)
 return 0;
 }
 
-static void set_memory_target(uint32_t domid, const char *mem)
+static int set_memory_target(uint32_t domid, const char *mem)
 {
-long long int memorykb;
+int64_t memorykb;
+int rc;
 
 memorykb = parse_mem_size_kb(mem);
 if (memorykb == -1)  {
@@ -3307,7 +3308,9 @@ static void set_memory_target(uint32_t domid, const char 
*mem)
 exit(3);
 }
 
-libxl_set_memory_target(ctx, domid, memorykb, 0, /* enforce */ 1);
+rc = libxl_set_memory_target(ctx, domid, memorykb, 0, /* enforce */ 1);
+
+return rc;
 }
 
 int main_memset(int argc, char **argv)
@@ -3315,6 +3318,7 @@ int main_memset(int argc, char **argv)
 uint32_t domid;
 int opt = 0;
 const char *mem;
+int rc;
 
 SWITCH_FOREACH_OPT(opt, "", NULL, "mem-set", 2) {
 /* No options */
@@ -3323,7 +3327,12 @@ int main_memset(int argc, char **argv)
 domid = find_domain(argv[optind]);
 mem = argv[optind + 1];
 
-set_memory_target(domid, mem);
+rc = set_memory_target(domid, mem);
+if (rc) {
+fprintf(stderr, "cannot set domid %d dynamic max memory to : %s\n", 
domid, mem);
+return 1;
+}
+
 return 0;
 }
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 5/6] xl: Return error codes for pci* commands

[George Dunlap]

Add return codes for pci-detach, pci-attach, pci-asssignable-add, and
pci-assignable-remove.

Returning error codes makes it easier for shell scripts to tell if a
command has failed or succeeded.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 56 
 1 file changed, 37 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 72ece2e..5f21c37 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3495,10 +3495,11 @@ int main_pcilist(int argc, char **argv)
 return 0;
 }
 
-static void pcidetach(uint32_t domid, const char *bdf, int force)
+static int pcidetach(uint32_t domid, const char *bdf, int force)
 {
 libxl_device_pci pcidev;
 XLU_Config *config;
+int rc = 0;
 
 libxl_device_pci_init(&pcidev);
 
@@ -3509,13 +3510,18 @@ static void pcidetach(uint32_t domid, const char *bdf, 
int force)
 fprintf(stderr, "pci-detach: malformed BDF specification \"%s\"\n", 
bdf);
 exit(2);
 }
-if (force)
-libxl_device_pci_destroy(ctx, domid, &pcidev, 0);
-else
-libxl_device_pci_remove(ctx, domid, &pcidev, 0);
+if (force) {
+if(libxl_device_pci_destroy(ctx, domid, &pcidev, 0))
+rc = 1;
+} else {
+if(libxl_device_pci_remove(ctx, domid, &pcidev, 0))
+rc = 1;
+}
 
 libxl_device_pci_dispose(&pcidev);
 xlu_cfg_destroy(config);
+
+return rc;
 }
 
 int main_pcidetach(int argc, char **argv)
@@ -3534,13 +3540,14 @@ int main_pcidetach(int argc, char **argv)
 domid = find_domain(argv[optind]);
 bdf = argv[optind + 1];
 
-pcidetach(domid, bdf, force);
-return 0;
+return pcidetach(domid, bdf, force);
 }
-static void pciattach(uint32_t domid, const char *bdf, const char *vs)
+
+static int pciattach(uint32_t domid, const char *bdf, const char *vs)
 {
 libxl_device_pci pcidev;
 XLU_Config *config;
+int rc;
 
 libxl_device_pci_init(&pcidev);
 
@@ -3551,10 +3558,14 @@ static void pciattach(uint32_t domid, const char *bdf, 
const char *vs)
 fprintf(stderr, "pci-attach: malformed BDF specification \"%s\"\n", 
bdf);
 exit(2);
 }
-libxl_device_pci_add(ctx, domid, &pcidev, 0);
+
+if(libxl_device_pci_add(ctx, domid, &pcidev, 0))
+rc = 1;
 
 libxl_device_pci_dispose(&pcidev);
 xlu_cfg_destroy(config);
+
+return rc;
 }
 
 int main_pciattach(int argc, char **argv)
@@ -3573,8 +3584,7 @@ int main_pciattach(int argc, char **argv)
 if (optind + 1 < argc)
 vs = argv[optind + 2];
 
-pciattach(domid, bdf, vs);
-return 0;
+return pciattach(domid, bdf, vs);
 }
 
 static void pciassignable_list(void)
@@ -3606,10 +3616,11 @@ int main_pciassignable_list(int argc, char **argv)
 return 0;
 }
 
-static void pciassignable_add(const char *bdf, int rebind)
+static int pciassignable_add(const char *bdf, int rebind)
 {
 libxl_device_pci pcidev;
 XLU_Config *config;
+int rc = 0;
 
 libxl_device_pci_init(&pcidev);
 
@@ -3620,10 +3631,14 @@ static void pciassignable_add(const char *bdf, int 
rebind)
 fprintf(stderr, "pci-assignable-add: malformed BDF specification 
\"%s\"\n", bdf);
 exit(2);
 }
-libxl_device_pci_assignable_add(ctx, &pcidev, rebind);
+
+if (libxl_device_pci_assignable_add(ctx, &pcidev, rebind))
+rc = 1;
 
 libxl_device_pci_dispose(&pcidev);
 xlu_cfg_destroy(config);
+
+return rc;
 }
 
 int main_pciassignable_add(int argc, char **argv)
@@ -3637,14 +3652,14 @@ int main_pciassignable_add(int argc, char **argv)
 
 bdf = argv[optind];
 
-pciassignable_add(bdf, 1);
-return 0;
+return pciassignable_add(bdf, 1);
 }
 
-static void pciassignable_remove(const char *bdf, int rebind)
+static int pciassignable_remove(const char *bdf, int rebind)
 {
 libxl_device_pci pcidev;
 XLU_Config *config;
+int rc = 0;
 
 libxl_device_pci_init(&pcidev);
 
@@ -3655,10 +3670,14 @@ static void pciassignable_remove(const char *bdf, int 
rebind)
 fprintf(stderr, "pci-assignable-remove: malformed BDF specification 
\"%s\"\n", bdf);
 exit(2);
 }
-libxl_device_pci_assignable_remove(ctx, &pcidev, rebind);
+
+if(libxl_device_pci_assignable_remove(ctx, &pcidev, rebind))
+rc = 1;
 
 libxl_device_pci_dispose(&pcidev);
 xlu_cfg_destroy(config);
+
+return rc;
 }
 
 int main_pciassignable_remove(int argc, char **argv)
@@ -3675,8 +3694,7 @@ int main_pciassignable_remove(int argc, char **argv)
 
 bdf = argv[optind];
 
-pciassignable_remove(bdf, rebind);
-return 0;
+return pciassignable_remove(bdf, rebind);
 }
 
 static void pause_domain(uint32_t domid)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 2/6] libxl: Fix libxl_set_memory_target return value

[George Dunlap]

libxl_set_memory_target seems to have the following return values:

* 1 on failure, if the failure happens because of a xenstore error *or* invalid 
target

* -1 if the setmaxmem hypercall

* -errno if the set_pod_target hypercall target fails

* 1 on success (!)

Make it consistenstly return ERROR_FAIL, unless the parameters were
invalid.

To make this more robust, use 'lrc' for return values to functions
whose return values are a different error space (like
xc_domain_setmaxmem and xc_domain_set_pod_target), or where a failure
means retry, rather than fail the whole function
(libxl__fill_dom0_memory_info), to reduce the risk that future code
shuffles will accidentally clobber the return value again.

Also remove the final call to xc_domain_getinfolist. There's no
obvious reason for this call -- all it seems to be doing is checking
to see if the domain exists; but if it doesn't exist, it will have
already failed by this point.

Signed-off-by: George Dunlap 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/libxl.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 814d056..f8a0642 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4722,7 +4722,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t 
domid,
 int32_t target_memkb, int relative, int enforce)
 {
 GC_INIT(ctx);
-int rc = 1, abort_transaction = 0;
+int rc = ERROR_FAIL, abort_transaction = 0, lrc;
 uint64_t memorykb;
 uint32_t videoram = 0;
 uint32_t current_target_memkb = 0, new_target_memkb = 0;
@@ -4750,9 +4750,9 @@ retry_transaction:
 if (!target && !domid) {
 if (!xs_transaction_end(ctx->xsh, t, 1))
 goto out_no_transaction;
-rc = libxl__fill_dom0_memory_info(gc, ¤t_target_memkb,
+lrc = libxl__fill_dom0_memory_info(gc, ¤t_target_memkb,
   ¤t_max_memkb);
-if (rc < 0)
+if (lrc < 0)
 goto out_no_transaction;
 goto retry_transaction;
 } else if (!target) {
@@ -4800,6 +4800,7 @@ retry_transaction:
 "memory_dynamic_max must be less than or equal to"
 " memory_static_max\n");
 abort_transaction = 1;
+rc = ERROR_INVAL;
 goto out;
 }
 
@@ -4807,43 +4808,39 @@ retry_transaction:
 LOG(ERROR, "new target %d for dom0 is below the minimum threshold",
 new_target_memkb);
 abort_transaction = 1;
+rc = ERROR_INVAL;
 goto out;
 }
 
 if (enforce) {
 memorykb = new_target_memkb + videoram;
-rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
+lrc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
 LIBXL_MAXMEM_CONSTANT);
-if (rc != 0) {
+if (lrc != 0) {
 LOGE(ERROR,
  "xc_domain_setmaxmem domid=%u memkb=%"PRIu64" failed 
""rc=%d\n",
  domid,
  memorykb + LIBXL_MAXMEM_CONSTANT,
- rc);
+ lrc);
 abort_transaction = 1;
 goto out;
 }
 }
 
-rc = xc_domain_set_pod_target(ctx->xch, domid,
+lrc = xc_domain_set_pod_target(ctx->xch, domid,
 (new_target_memkb + LIBXL_MAXMEM_CONSTANT) / 4, NULL, NULL, NULL);
-if (rc != 0) {
+if (lrc != 0) {
 LOGE(ERROR,
  "xc_domain_set_pod_target domid=%d, memkb=%d ""failed rc=%d\n",
  domid,
  new_target_memkb / 4,
- rc);
+ lrc);
 abort_transaction = 1;
 goto out;
 }
 
 libxl__xs_write(gc, t, GCSPRINTF("%s/memory/target",
 dompath), "%"PRIu32, new_target_memkb);
-rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
-if (rc != 1 || info.domain != domid) {
-abort_transaction = 1;
-goto out;
-}
 
 libxl_dominfo_init(&ptr);
 xcinfo2xlinfo(ctx, &info, &ptr);
@@ -4852,6 +4849,8 @@ retry_transaction:
 "%"PRIu32, new_target_memkb / 1024);
 libxl_dominfo_dispose(&ptr);
 
+rc = 0;
+
 out:
 if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
 && !abort_transaction)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Ian Campbell]

On Tue, 2015-12-01 at 11:39 +, Wei Liu wrote:
> There were some problems with the original memory allocation functions:
> 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
>    xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
> 2. xc_dom_alloc_pad didn't call dom->allocate.
> 
> Refactor the code so that:
> 1. xc_dom_alloc_{segment,pad,page} end up calling
>    xc_dom_chk_alloc_pages.
> 2. xc_dom_chk_alloc_pages calls dom->allocate.
> 
> This way we avoid scattering dom->allocate over multiple locations and
> open-coding.
> 
> Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
> an invalid pfn when xc_dom_chk_alloc_pages fails.

Given this presumably the handful of callers ought to gain some error
handling in a followup patch?

xc_dom_chk_alloc_pages does log, so at least the callers needn't bother
with that.

> Signed-off-by: Wei Liu 

Acked-by: Ian Campbell 

> ---
> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Juergen Gross 
> 
> We don't have INVALID_PFN, maybe we need one?

We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the
bill (or if not how it is distinct from the former).

> 
> Tested with Jessie with 64 bit pvgrub, Wheezy with 64 bit pvgrub, Wheezy
> pv
> guest, Wheezy HVM guest, Wheezy HVM with qemu stubdom.

Also by me in my previously failing environment =>

Tested-by: Ian Campbell 

I think there are two more fixes in this space:
libxc: correct domain builder for 64 bit guest with 32 bit tools
libxc: use correct return type for do_memory_op()

I intend to pick up all three for commit in a moment, prod me if there are
others.

> 
>  tools/libxc/include/xc_dom.h |  2 +-
>  tools/libxc/xc_dom_core.c| 16 +++-
>  2 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 2176216..2d0de8c 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -350,7 +350,7 @@ char *xc_dom_strdup(struct xc_dom_image *dom, const
> char *str);
>  
>  /* --- alloc memory pool --- */
>  
> -int xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
> +xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
>  int xc_dom_alloc_segment(struct xc_dom_image *dom,
>   struct xc_dom_seg *seg, char *name,
>   xen_vaddr_t start, xen_vaddr_t size);
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index 5d6c3ba..8967970 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -555,6 +555,9 @@ static int xc_dom_chk_alloc_pages(struct xc_dom_image
> *dom, char *name,
>  dom->pfn_alloc_end += pages;
>  dom->virt_alloc_end += pages * page_size;
>  
> +if ( dom->allocate )
> +dom->allocate(dom);
> +
>  return 0;
>  }
>  
> @@ -602,9 +605,6 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
>  if ( xc_dom_chk_alloc_pages(dom, name, pages) )
>  return -1;
>  
> -if (dom->allocate)
> -dom->allocate(dom);
> -
>  /* map and clear pages */
>  ptr = xc_dom_seg_to_ptr(dom, seg);
>  if ( ptr == NULL )
> @@ -621,18 +621,16 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
>  return 0;
>  }
>  
> -int xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
> +xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
>  {
> -unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
>  xen_vaddr_t start;
>  xen_pfn_t pfn;
>  
>  start = dom->virt_alloc_end;
>  pfn = dom->pfn_alloc_end - dom->rambase_pfn;
> -dom->virt_alloc_end += page_size;
> -dom->pfn_alloc_end++;
> -if ( dom->allocate )
> -dom->allocate(dom);
> +
> +if ( xc_dom_chk_alloc_pages(dom, name, 1) )
> +return (xen_pfn_t)-1;
>  
>  DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " (pfn 0x%" PRIpfn ")",
>    __FUNCTION__, name, start, pfn);

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Wei Liu]

On Tue, Dec 01, 2015 at 11:58:44AM +, Ian Campbell wrote:
> On Tue, 2015-12-01 at 11:39 +, Wei Liu wrote:
> > There were some problems with the original memory allocation functions:
> > 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
> >    xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
> > 2. xc_dom_alloc_pad didn't call dom->allocate.
> > 
> > Refactor the code so that:
> > 1. xc_dom_alloc_{segment,pad,page} end up calling
> >    xc_dom_chk_alloc_pages.
> > 2. xc_dom_chk_alloc_pages calls dom->allocate.
> > 
> > This way we avoid scattering dom->allocate over multiple locations and
> > open-coding.
> > 
> > Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
> > an invalid pfn when xc_dom_chk_alloc_pages fails.
> 
> Given this presumably the handful of callers ought to gain some error
> handling in a followup patch?
> 

Yes, that's for sure.

> xc_dom_chk_alloc_pages does log, so at least the callers needn't bother
> with that.
> 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Ian Campbell 
> 
> > ---
> > Cc: Ian Campbell 
> > Cc: Ian Jackson 
> > Cc: Juergen Gross 
> > 
> > We don't have INVALID_PFN, maybe we need one?
> 
> We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the
> bill (or if not how it is distinct from the former).
> 

Yeah, I'm aware of those but they don't seem to fit because they are
used in MFN space.

> > 
> > Tested with Jessie with 64 bit pvgrub, Wheezy with 64 bit pvgrub, Wheezy
> > pv
> > guest, Wheezy HVM guest, Wheezy HVM with qemu stubdom.
> 
> Also by me in my previously failing environment =>
> 
> Tested-by: Ian Campbell 
> 
> I think there are two more fixes in this space:
> libxc: correct domain builder for 64 bit guest with 32 bit tools
> libxc: use correct return type for do_memory_op()
> 
> I intend to pick up all three for commit in a moment, prod me if there are
> others.
> 

This one and the other two are all that I'm aware of at the moment.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Juergen Gross]

On 01/12/15 12:58, Ian Campbell wrote:
> On Tue, 2015-12-01 at 11:39 +, Wei Liu wrote:
>> There were some problems with the original memory allocation functions:
>> 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
>>xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
>> 2. xc_dom_alloc_pad didn't call dom->allocate.
>>
>> Refactor the code so that:
>> 1. xc_dom_alloc_{segment,pad,page} end up calling
>>xc_dom_chk_alloc_pages.
>> 2. xc_dom_chk_alloc_pages calls dom->allocate.
>>
>> This way we avoid scattering dom->allocate over multiple locations and
>> open-coding.
>>
>> Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
>> an invalid pfn when xc_dom_chk_alloc_pages fails.
> 
> Given this presumably the handful of callers ought to gain some error
> handling in a followup patch?

I could do that. Wei?

> 
> xc_dom_chk_alloc_pages does log, so at least the callers needn't bother
> with that.
> 
>> Signed-off-by: Wei Liu 
> 
> Acked-by: Ian Campbell 
> 
>> ---
>> Cc: Ian Campbell 
>> Cc: Ian Jackson 
>> Cc: Juergen Gross 
>>
>> We don't have INVALID_PFN, maybe we need one?
> 
> We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the
> bill (or if not how it is distinct from the former).

What about merging all of them into INVALID_FRAME?

I can create a patch(-series).


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxl: Introduce a template for devices with a controller

[Ian Campbell]

On Tue, 2015-11-24 at 14:40 +, George Dunlap wrote:
> We have several outstanding patch series which add devices that have
> two levels: a controller and individual devices attached to that
> controller.
> 
> In the interest of consistency, this patch introduces a section that
> sketches out a template for interfaces for such devices.
> 
> Signed-off-by: George Dunlap 

With the previously reported (by Juergen and Chyn Yan) typoes fixed:

Acked-by: Ian Campbell > 

FWIW (which may not be much) some dev types (e.g. PCI) collapse one or more
of your "" into a single one by having multiple devid things
encoded in one way or another in the struct, e.g. libxl_device_pci has bus,
device, func etc as fields.

Not sure if that is worth mentioning (or encouraging) as a possibility for
other device types (assuming it makes sense in that schema)

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Juergen Gross 
> CC: Chun Yan Liu 
> CC: Olaf Hering 
> 
> Changes in v1 (since the RFC):
> 
> - Use  rather than , and  rather than specifying
>   controller and device.  The idea being to allow SCSI to use
>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun)
>   rather than naming things after USB (controller & device).
> 
> - Do not require each  to have a deviceid, but just a unique
>   naming schema.
> 
> - Allow multiple levels.
> 
> - Include the paragraph about domain configuration lists.
> ---
>  tools/libxl/libxl.h | 65
> +
>  1 file changed, 65 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6b73848..46bcfe8 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *,
> int nr_vtpms);
>   *
>   *   This function does not interact with the guest and therefore
>   *   cannot block on the guest.
> + *
> + * Controllers
> + * ---
> + *
> + * Most devices are treated individually.  Some classes of device,
> + * however, like USB or SCSI, inherently have the need to have a
> + * heiarchy of different levels, with lower-level devices "attached"
> + * to higher-level ones.  USB for instance has "controllers" at the
> + * top, which have busses, on which are devices, which consist of
> + * multiple interfaces.  SCSI has "hosts" at the top, then busses,
> + * targets, and LUNs.
> + *
> + * In that case, for each , there will be a set of funcitons
> + * and types for each .  For example, for =usb, there
> + * may be  ctrl (controller) and dev (device), with ctrl being
> + * level 0.
> + *
> + * libxl_device__ will act more or
> + * less like top-level non-bus devices: they will either create or
> + * accept a libxl_devid which will be unique within the
> + *  libxl_devid namespace.
> + *
> + * Lower-level devices must have a unique way to be identified.  One
> + * way to do this would be to name it via the name of the next level
> + * up plus an index; for instance, .  Another
> + * way would be to have another devid namespace for that level.  This
> + * identifier will be used for queries and removals.
> + *
> + * Lower-level devices will will include in their
> + * libxl_device_ struct a field referring to the unique
> + * index of the level above.  For instance, libxl_device_usbdev might
> + * contain the controller devid.
> + *
> + * In the case where there are multiple different ways to implement a
> + * given device -- for instance, one which is fully PV and one which
> + * uses an emulator -- the controller will contain a field which
> + * specifies what type of implementation is used.  The implementations
> + * of individual devices will be known by the controller to which they
> + * are attached.
> + *
> + * If libxl_device__add receives an empty reference to
> + * the level above, it may return an error.  Or it may (but is not
> + * required to) automatically choose a suitable device in the level
> + * above to which to attach the new device at this level.  It may also
> + * (but is not required to) automatically create a new device at the
> + * level above if no suitable devices exist.  Each class should
> + * document its behavior.
> + *
> + * libxl_device__list will list all devices of 
> + * at  in the domain.  For example, libxl_class_usbctrl_list
> + * will list all usb controllers; libxl_class_usbdev_list will list
> + * all usb devices across all controllers.
> + *
> + * For each class, the domain config file will contain a single list
> + * for each level.  libxl will first iterate through the list of
> + * top-level devices, then iterate through each level down in turn,
> + * adding devices to devices in the level above.  For instance, there
> + * will be one list for all usb controllers, and one list for all usb
> + * devices.
> + * 
> + * If libxl_device__add automatically creates
> + * higher-level devices as necessary, then it is permissible for the
> + * higher-level lists to be empty and the dev

[Xen-devel] [PATCH v2] libxl: Introduce a template for devices with a controller

[George Dunlap]

We have several outstanding patch series which add devices that have
two levels: a controller and individual devices attached to that
controller.

In the interest of consistency, this patch introduces a section that
sketches out a template for interfaces for such devices.

Signed-off-by: George Dunlap 
Acked-by: Juergen Gross 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
CC: Chun Yan Liu 
CC: Olaf Hering 

Changes in v2:
- Fixed typos

Changes in v1 (since the RFC):

- Use  rather than , and  rather than specifying
  controller and device.  The idea being to allow SCSI to use
  terminology more natural to it (i.e., scsihost, scsitarget, scsilun)
  rather than naming things after USB (controller & device).

- Do not require each  to have a deviceid, but just a unique
  naming schema.

- Allow multiple levels.

- Include the paragraph about domain configuration lists.
---
 tools/libxl/libxl.h | 65 +
 1 file changed, 65 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6b73848..44e2951 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int 
nr_vtpms);
  *
  *   This function does not interact with the guest and therefore
  *   cannot block on the guest.
+ *
+ * Controllers
+ * ---
+ *
+ * Most devices are treated individually.  Some classes of device,
+ * however, like USB or SCSI, inherently have the need to have a
+ * hierarchy of different levels, with lower-level devices "attached"
+ * to higher-level ones.  USB for instance has "controllers" at the
+ * top, which have buses, on which are devices, which consist of
+ * multiple interfaces.  SCSI has "hosts" at the top, then buses,
+ * targets, and LUNs.
+ *
+ * In that case, for each , there will be a set of functions
+ * and types for each .  For example, for =usb, there
+ * may be  ctrl (controller) and dev (device), with ctrl being
+ * level 0.
+ *
+ * libxl_device__ will act more or
+ * less like top-level non-bus devices: they will either create or
+ * accept a libxl_devid which will be unique within the
+ *  libxl_devid namespace.
+ *
+ * Lower-level devices must have a unique way to be identified.  One
+ * way to do this would be to name it via the name of the next level
+ * up plus an index; for instance, .  Another
+ * way would be to have another devid namespace for that level.  This
+ * identifier will be used for queries and removals.
+ *
+ * Lower-level devices will include in their
+ * libxl_device_ struct a field referring to the unique
+ * index of the level above.  For instance, libxl_device_usbdev might
+ * contain the controller devid.
+ *
+ * In the case where there are multiple different ways to implement a
+ * given device -- for instance, one which is fully PV and one which
+ * uses an emulator -- the controller will contain a field which
+ * specifies what type of implementation is used.  The implementations
+ * of individual devices will be known by the controller to which they
+ * are attached.
+ *
+ * If libxl_device__add receives an empty reference to
+ * the level above, it may return an error.  Or it may (but is not
+ * required to) automatically choose a suitable device in the level
+ * above to which to attach the new device at this level.  It may also
+ * (but is not required to) automatically create a new device at the
+ * level above if no suitable devices exist.  Each class should
+ * document its behavior.
+ *
+ * libxl_device__list will list all devices of 
+ * at  in the domain.  For example, libxl_device_usbctrl_list
+ * will list all usb controllers; libxl_class_usbdev_list will list
+ * all usb devices across all controllers.
+ *
+ * For each class, the domain config file will contain a single list
+ * for each level.  libxl will first iterate through the list of
+ * top-level devices, then iterate through each level down in turn,
+ * adding devices to devices in the level above.  For instance, there
+ * will be one list for all usb controllers, and one list for all usb
+ * devices.
+ * 
+ * If libxl_device__add automatically creates
+ * higher-level devices as necessary, then it is permissible for the
+ * higher-level lists to be empty and the device list to have devices
+ * with the field containing a reference to the higher level device
+ * uninitialized.
  */
 
 /* Disks */
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Wei Liu]

On Tue, Dec 01, 2015 at 01:04:14PM +0100, Juergen Gross wrote:
> On 01/12/15 12:58, Ian Campbell wrote:
> > On Tue, 2015-12-01 at 11:39 +, Wei Liu wrote:
> >> There were some problems with the original memory allocation functions:
> >> 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
> >>xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
> >> 2. xc_dom_alloc_pad didn't call dom->allocate.
> >>
> >> Refactor the code so that:
> >> 1. xc_dom_alloc_{segment,pad,page} end up calling
> >>xc_dom_chk_alloc_pages.
> >> 2. xc_dom_chk_alloc_pages calls dom->allocate.
> >>
> >> This way we avoid scattering dom->allocate over multiple locations and
> >> open-coding.
> >>
> >> Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
> >> an invalid pfn when xc_dom_chk_alloc_pages fails.
> > 
> > Given this presumably the handful of callers ought to gain some error
> > handling in a followup patch?
> 
> I could do that. Wei?
> 

You're welcome to pick that up.

> > 
> > xc_dom_chk_alloc_pages does log, so at least the callers needn't bother
> > with that.
> > 
> >> Signed-off-by: Wei Liu 
> > 
> > Acked-by: Ian Campbell 
> > 
> >> ---
> >> Cc: Ian Campbell 
> >> Cc: Ian Jackson 
> >> Cc: Juergen Gross 
> >>
> >> We don't have INVALID_PFN, maybe we need one?
> > 
> > We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the
> > bill (or if not how it is distinct from the former).
> 
> What about merging all of them into INVALID_FRAME?
> 

Note that INVALID_MFN is in public header (xenctrl.h) while
INVALID_P2M_ENTRY is not.

In fact (xen_pfn_t)-1 is part of guest ABI so we should properly export
and document it. The current situation is not ideal. Not sure how much
yak shaving is required though.

Wei.

> I can create a patch(-series).
> 
> 
> Juergen
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Ian Campbell]

On Tue, 2015-12-01 at 12:03 +, Wei Liu wrote:
> 
> > > We don't have INVALID_PFN, maybe we need one?
> > 
> > We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the
> > bill (or if not how it is distinct from the former).
> > 
> 
> Yeah, I'm aware of those but they don't seem to fit because they are
> used in MFN space.

Right, I wasn't sure about the latter, since given a P2M_ENTRY is an MFN I
then don't see how/why it is distinct from INVALID_MFN. Perhaps I'm missing
something (guest p2m width perhaps?), or maybe it's just historical
baggage.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle

[Lars Kurth]

> On 11 Nov 2015, at 16:33, Wei Liu  wrote:
> 
> FWIW I think it would be valuable if we can CC some vendors /
> contributors and get feedback from them.

I highlighted this at the Advisory Board meeting and the board is supportive. 
Concrete feedback was
A) "I'm generally supportive of this because I believe it will help reduce 
ambiguities around the status of features and ultimately help improve quality." 
This was mirrored by everyone at the last meeting. 
B) The preview vs. experimental classification was deemed to be a bit 
arbitrary, and maybe we can fold them into one category. The feeling was that 
the distinction does not provide much value and we should maybe come up with 
something simpler.
C) A concern raised was that by being explicit about "legacy" features we may 
create negative PR opportunities, e.g. "the Xen Project has declared 50% of its 
features to be untested and undocumented". Perhaps instead we just grandfather 
these features into "stable" rather than having an explicit "legacy-stable" 
designation.

Another possible solution would be to be clear about what is automatically 
tested and what requires manual testing (or is currently tested by 3rd party 
test infrastructure such as XenRT and others) in the "Supported" category. The 
argument that can be made is that for "legacy-stable" we rely on 3rd party 
testing. This would help direct test resources during Test Days towards such 
features. 

The documentation angle is probably less of an issue, because we have user 
facing docs for pretty much everything in the man pages. So we basically mainly 
talk about specs and other documents which are either in the wiki or in 
docs/misc. And of course we can make judgement calls for those docs in pretty 
much the same way as we do now.

Any views on the pros and cons?
 
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] dom builder logging from pvgrub.

[Samuel Thibault]

Ian Campbell, on Tue 01 Dec 2015 11:12:36 +, wrote:
> I found the following hack quite handy here. Posting it for the
> archives/posterity, I don't really plan to clean it up and submit it
> properly (since I'm not really sure what a non-hack version would be).

I would say a non-hack version could be simply one with #ifdef DEBUG. We
don't really want to make pv-grub be so verbose by default, but having
the code off-hand to debug things would be really welcome.

Samuel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle

[Lars Kurth]

> On 11 Nov 2015, at 19:38, Andrew Cooper  wrote:
> 
> On 06/11/15 17:35, Lars Kurth wrote:
>> +# State Definitions
>> +
>> +This section lists state definitions of a **Feature** in terms of
>> +properties. This section talks about Features, for readability, but
>> +is used interchangeably between **Features** and **Platforms**.
>> +
>> +States are listed in order of increasing number
>> +of properties. Note that note all features will require to go
>> +through each state: for example small and non-risky features
>> +may go straight from under development to supported. It is up to
>> +the development community to judge and discuss, which states
>> +are necessary based on the size and risk of a feature.
>> +
>> +## Preview
>> +* Partially completed, with missing functionality
>> +* May **not be fully functional** in all cases
>> +* May **not be tested**
>> +* APIs and interfaces may **not be stable**
> 
> "are not stable".
> 
> i.e. maintainers reserve the right to insist that the interfaces are
> changed.

OK. That makes sense

> 
> For preview and experimental features, it is quite possible that hidden
> design considerations become visible after the initial code is committed.
> 
> As a result, it is important that nothing is set in stone while the
> feature itself is still in development.

Agreed. 


>> +* The developer is actively looking for user feedback
>> +* Bugs and issues can be raised on xen-devel@ and will be
>> +  handled on a best-effort basis
> 
> Probably best to explicitly state that there is no security support for
> Preview/Experimental features.  By their classification, they are not
> ready for production use.

Agreed.

>> +
>> +## Experimental
>> +* Core functionality is **fully functional**
>> +* However, not all functionality or platform support may be
>> +  present
>> +* May **not be tested**, although there is an expectation that a plan
>> +  to improve testing is in place or worked on
>> +* APIs and interfaces may **not be stable**
>> +* Bugs and issues can be raised on xen-devel@ and will be
>> +  handled on a best-effort basis. However, there is an expectation
>> +  that issues related to broken core functionality are addressed.
> 
> I am not completely convinced by splitting Preview and Experiential. 
> The difference between the two is quite subjective.
> 
> I would hope that the exact state of the feature in the range Nothing ->
> Supported is easy to derive from the Limitations, Improvements and Known
> Issues sections of its feature document.

Alright. That makes sense and is also mirrored somewhat by the Advisory Board 
feedback (see my last mail to Wei).
What is your view on the usefulness of keeping Preview and Experimental 
separate? It sounds to me that we should fold these into one category and let 
Limitations, Improvements and Known Issues speak for themselves.

Lars 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 65258: all pass - PUSHED

[osstest service owner]

flight 65258 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65258/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 8786ba4fe7220d24c41bf1386b7186eabda00a0c
baseline version:
 ovmf 81438fe8d0fc63f9bc9fcee0113baf6bd395f29c

Last test of basis65244  2015-11-30 02:12:34 Z1 days
Testing same since65258  2015-11-30 14:43:23 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Ruiyu Ni 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=8786ba4fe7220d24c41bf1386b7186eabda00a0c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
8786ba4fe7220d24c41bf1386b7186eabda00a0c
+ branch=ovmf
+ revision=8786ba4fe7220d24c41bf1386b7186eabda00a0c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x8786ba4fe7220d24c41bf1386b7186eabda00a0c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fe

Re: [Xen-devel] Xen 4.7 Development Update

[Wei Liu]

On Tue, Dec 01, 2015 at 11:54:54AM +, Lars Kurth wrote:
> Wei, and others.
> 
> > On 25 Nov 2015, at 02:17, Han, Huaitong 
> > wrote:
> >> 
> >> = Projects =
> > 
> > == Hypervisor == === x86 === *Memory protection keys for user pages
> > -Huaitong Han
> 
> one thing I struggle with (and I am probably not the only one), is
> that it is not always easy do find out what a specific patch does in
> the Development Update mails. Obviously this is not an issue at the
> beginning of the cycle, but it can become one when we start to put the
> release notes and PR together. In this particular case, the use-case
> for the feature was described as a one-liner else-where and I am
> wondering, whether we should allow tracking the use/use-case/... in
> these mails.
> 
> Aka, in this case, using the information from the thread where the
> use-case was discussed, will give us something like ...  
> 
> == Hypervisor == === x86 === * Memory protection keys for user pages
> (allows threads to cooperatively prevent themselves from "trampling"
> on each other, which increases robustness and is useful for debugging)
> - Huaitong Han
> 
> Part of the reason, why I am also looking at this, is because of the
> Feature Lifecycle Management (see
> http://xen.markmail.org/message/uu3vifjmv2qylds4), where we still have
> outstanding issues on documenting completed features. It seems to me
> that there is an overlap between the Development Update mails, and
> recording the state of an added feature in a central file. Obviously,
> if a new feature was committed to xen.git, we would then need to add
> an entry to the still to be defined central file describing it. And it
> would probably make sense to keep the info in Development Update mails
> as close as possible to what is in the still to be defined file.
> 


I can't think of how you would merge such document and this email as a
whole. Most things in this mail are unfinished so they haven't entered
FML. If there is ever overlapped, that is the "completed" section of
this mail -- it makes sense to keep that section close to the in-tree
document. But on the flip side we don't need two places for the same
thing so I would just remove the completed section all together and
refer to the in-tree document.

As for PR purpose it would be easy during freeze to send out emails to
people to have them write a small paragraph. They are also welcome to
provide such information to this email -- I shall say that in preamble.

Wei.

> Any thoughts?
> 
> Cheers Lars 
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/2] libxl: change libxl__xs_mkdir() to libxl__xs_mknod()

[Ian Campbell]

On Wed, 2015-11-25 at 14:50 +, Paul Durrant wrote:
> Patch #1 is purely a search and replace
> Patch #2 changes the underlying implementation

Applied both.

I think these used to be part of "libxl: xenstore related cleanup", did
this series completely replace that or are there still aspects yet to come
and/or be reposted?


> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: use correct return type for do_memory_op()

[Ian Campbell]

On Mon, 2015-11-30 at 10:23 +, Wei Liu wrote:
> On Fri, Nov 27, 2015 at 10:00:51AM +0100, Juergen Gross wrote:
> > Currently do_memory_op() is returning int, while the hypervisor is
> > returning long. This will lead to wrong return informations as soon as
> > e.g. a pfn larger than about 2 billion (8 TB) is returned.
> > 
> > Use the correct long return type instead and correct the functions
> > expecting a pfn via the return value of do_memory_op().
> > 
> > Signed-off-by: Juergen Gross 
> 
> Acked-by: Wei Liu 

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: correct domain builder for 64 bit guest with 32 bit tools

[Ian Campbell]

On Tue, 2015-12-01 at 10:07 +, Wei Liu wrote:
> On Tue, Dec 01, 2015 at 08:49:49AM +0100, Juergen Gross wrote:
> > Commit 8c45adec18e0512c3d34dcafb13414ecba21be6a ("create unmapped
> > initrd in domain builder if supported") introduced an error for
> > building a 64 bit guest with a 32 bit toolset.
> > 
> > The initrd start address and size where stored in an unsigned long
> > instead of using a 64 bit type.
> > 
> > Signed-off-by: Juergen Gross 
> > Tested-by: Boris Ostrovsky 
> 
> Acked-by: Wei Liu 

Applied, thanks.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] ocaml/xc: add softreset shutdown reason

[Ian Campbell]

On Thu, 2015-11-26 at 12:13 +, David Scott wrote:
> > On 26 Nov 2015, at 12:11, Wei Liu  wrote:
> > 
> > Dave, ping?
> 
> Sorry, completely forgot about this email.
> 
> Looks totally fine to me!
> 
> Acked-by: David Scott 

Applied, thanks.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Ian Campbell]

On Tue, 2015-12-01 at 12:45 +0100, Juergen Gross wrote:
> On 01/12/15 12:39, Wei Liu wrote:
> > There were some problems with the original memory allocation functions:
> > 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
> >    xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded
> > everything.
> > 2. xc_dom_alloc_pad didn't call dom->allocate.
> > 
> > Refactor the code so that:
> > 1. xc_dom_alloc_{segment,pad,page} end up calling
> >    xc_dom_chk_alloc_pages.
> > 2. xc_dom_chk_alloc_pages calls dom->allocate.
> > 
> > This way we avoid scattering dom->allocate over multiple locations and
> > open-coding.
> > 
> > Also change the return type of xc_dom_alloc_page to xen_pfn_t and
> > return
> > an invalid pfn when xc_dom_chk_alloc_pages fails.
> > 
> > Signed-off-by: Wei Liu 
> 
> Reviewed-by: Juergen Gross 

Applied, thanks.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: fix clean rule to cover objects in unvisited subdirs

[Jan Beulich]

>>> On 30.11.15 at 18:29,  wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -173,7 +173,7 @@ FORCE:
>  
>  .PHONY: clean
>  clean:: $(addprefix _clean_, $(subdir-all))
> - rm -f *.o *~ core $(DEPS)
> + rm -f *.o *~ core $(DEPS) $(obj-y)

While for the moment it would do, using a minimalistic approach
like this will make us touch this again the moment we gain files in
subdirectories that can be built just optionally. At the very least
I'd therefore suggest also adding $(obj-n) and $(obj-) here. It
might even be reasonable to grab subdirectories from $(obj-...)
and add $(foreach d,$(filtered-subdirs), $(d)/*.o). Or, completely
differently, have xen/common/Makefile just have an add-on
clean:: (and require this also for future other cases like this).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7 Development Update

[Ian Campbell]

On Tue, 2015-12-01 at 12:35 +, Wei Liu wrote:
> 
> As for PR purpose it would be easy during freeze to send out emails to
> people to have them write a small paragraph. They are also welcome to
> provide such information to this email -- I shall say that in preamble.

Would "git diff RELEASE-4.6.0 RELEASE-4.7.0" -- docs/features" be
sufficient for PR purposes? (assuming we actually add stuff there...)

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 1/3] xsave: fix initialization of FPU memory area

[Roger Pau Monne]

When the CPU supports XSAVE, the initialization of the FPU memory area is
done during allocation of the XSAVE area. This is different from the way
it's done in non-xsave capable CPUs, so unify both paths and always
initialise the FPU state in vcpu_restore_fpu_lazy.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/i387.c   | 2 +-
 xen/arch/x86/xstate.c | 8 
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index b661d39..fcd87a6 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -226,7 +226,7 @@ void vcpu_restore_fpu_lazy(struct vcpu *v)
 if ( v->fpu_dirtied )
 return;
 
-if ( cpu_has_xsave )
+if ( cpu_has_xsave && v->fpu_initialised )
 fpu_xrstor(v, XSTATE_LAZY);
 else if ( v->fpu_initialised )
 fpu_fxrstor(v);
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index b65da38..8007342 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -415,14 +415,6 @@ int xstate_alloc_save_area(struct vcpu *v)
 if ( save_area == NULL )
 return -ENOMEM;
 
-/*
- * Set the memory image to default values, but don't force the context
- * to be loaded from memory (i.e. keep save_area->xsave_hdr.xstate_bv
- * clear).
- */
-save_area->fpu_sse.fcw = FCW_DEFAULT;
-save_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
-
 v->arch.xsave_area = save_area;
 v->arch.xcr0 = 0;
 v->arch.xcr0_accum = 0;
-- 
1.9.5 (Apple Git-50.3)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7 Development Update

[Wei Liu]

On Tue, Dec 01, 2015 at 12:42:17PM +, Ian Campbell wrote:
> On Tue, 2015-12-01 at 12:35 +, Wei Liu wrote:
> > 
> > As for PR purpose it would be easy during freeze to send out emails to
> > people to have them write a small paragraph. They are also welcome to
> > provide such information to this email -- I shall say that in preamble.
> 
> Would "git diff RELEASE-4.6.0 RELEASE-4.7.0" -- docs/features" be
> sufficient for PR purposes? (assuming we actually add stuff there...)
> 

That's of course also doable (assuming we get FML into 4.7)

> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 0/3] Introduce a flags field to HVM CPU context

[Roger Pau Monne]

Hello,

This patch series tries to properly solve the problem seen with the HVMlite 
series, that Xen always assumes the FPU is initialised on CPU context 
restore.

Patch 1/3 is new in this iteration of the series, and aims to unify the way 
FPU area memory is initialised on xsave capable hosts vs non-xsave capable 
ones.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 3/3] Revert "libxc: create an initial FPU state for HVM guests"

[Roger Pau Monne]

This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad:

Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.

This was a stop-gap measure in order to unblock OSSTest Windows 7 failures
while a proper fix for the HVM CPU save/restore is being worked on.

This can now be reverted because a proper fix is in place and we can signal
in the save record whether the FPU is initialized or not.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxc/xc_dom_x86.c | 38 --
 1 file changed, 38 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 5ff33ca..50cceee 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -910,27 +910,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
-/*
- * The layout of the fpu context structure is the same for
- * both 32 and 64 bits.
- */
-struct {
-uint16_t fcw;
-uint16_t fsw;
-uint8_t ftw;
-uint8_t rsvd1;
-uint16_t fop;
-union {
-uint64_t addr;
-struct {
-uint32_t offs;
-uint16_t sel;
-uint16_t rsvd;
-};
-} fip, fdp;
-uint32_t mxcsr;
-uint32_t mxcsr_mask;
-} *fpu_ctxt;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -998,23 +977,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 /* Set the control registers. */
 bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
 
-/*
- * XXX: Set initial FPU state.
- *
- * This should be removed once Xen is able to know if the
- * FPU state saved is valid or not, now Xen always sets
- * fpu_initialised to true regardless of the FPU state.
- *
- * The code below mimics the FPU sate after executing
- * fninit
- * ldmxcsr 0x1f80
- */
-fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
-
-fpu_ctxt->fcw = 0x37f;
-fpu_ctxt->ftw = 0xff;
-fpu_ctxt->mxcsr = 0x1f80;
-
 /* Set the IP. */
 bsp_ctx.cpu.rip = dom->parms.phys_entry;
 
-- 
1.9.5 (Apple Git-50.3)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 2/3] xen/hvm: introduce a flags field in the CPU save record

[Roger Pau Monne]

Introduce a new flags field and use bit 0 to signal if the FPU has been
initialised or not. Previously Xen always wrongly assumed the FPU was
initialised on restore.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Zero the fpu save area if the FPU is not initialised. This avoids
   leaking hypervisor data.
 - Due to the previous patch in this series, slightly rework the way to load
   the FPU state in a xsave capable host.

Changes since v3:
 - Don't add a comment in the compat structure regaring the fpu_initialised
   field.
 - Rename fpu_initialised to flags and use it as a bit field. Bit 0 will be
   used to signal whether the fpu is initialised.
 - Only save the fpu context if it's initialised.
 - Only restore the fpu context from the save record if the fpu is
   initialised.
 - Check that unused bits in the flags field are 0.

Changes since v1:
 - Don't add yet another compat structure, new fields should always be added
   to the end of the existing structure and offsetof should be used to
   compare sizes.
 - Leave the previous compat structure as-is, since the field was not added
   to the end we cannot remove it and use offsetof in this case.
 - Set xstate_bv based on fpu_initialised value instead of unconditionally
   setting it to XSTATE_FP_SSE.
---
 xen/arch/x86/hvm/hvm.c | 42 +++---
 xen/include/public/arch-x86/hvm/save.h | 27 --
 2 files changed, 49 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index db0aeba..ffb3b16 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1797,9 +1797,15 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 ctxt.ldtr_arbytes = seg.attr.bytes;
 
 if ( v->fpu_initialised )
+{
 memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs));
-else 
-memset(ctxt.fpu_regs, 0, sizeof(ctxt.fpu_regs));
+ctxt.flags = XEN_X86_FPU_INITIALISED;
+}
+else
+{
+ memset(ctxt.fpu_regs, 0, sizeof(ctxt.fpu_regs));
+ ctxt.flags = 0;
+}
 
 ctxt.rax = v->arch.user_regs.eax;
 ctxt.rbx = v->arch.user_regs.ebx;
@@ -1979,7 +1985,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( hvm_load_entry(CPU, h, &ctxt) != 0 ) 
+if ( hvm_load_entry_zeroextend(CPU, h, &ctxt) != 0 )
 return -EINVAL;
 
 /* Sanity check some control registers. */
@@ -2007,6 +2013,13 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
+if ( (ctxt.flags & ~XEN_X86_FPU_INITIALISED) != 0 )
+{
+gprintk(XENLOG_ERR, "bad flags value in CPU context: %#x\n",
+ctxt.flags);
+return -EINVAL;
+}
+
 /* Older Xen versions used to save the segment arbytes directly 
  * from the VMCS on Intel hosts.  Detect this and rearrange them
  * into the struct segment_register format. */
@@ -2085,19 +2098,23 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 seg.attr.bytes = ctxt.ldtr_arbytes;
 hvm_set_segment_register(v, x86_seg_ldtr, &seg);
 
-/* In case xsave-absent save file is restored on a xsave-capable host */
-if ( cpu_has_xsave && !xsave_enabled(v) )
+v->fpu_initialised = !!(ctxt.flags & XEN_X86_FPU_INITIALISED);
+if ( v->fpu_initialised )
 {
-struct xsave_struct *xsave_area = v->arch.xsave_area;
+memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
+/* In case xsave-absent save file is restored on a xsave-capable host 
*/
+if ( cpu_has_xsave && !xsave_enabled(v) )
+{
+struct xsave_struct *xsave_area = v->arch.xsave_area;
 
-memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
-xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
- XSTATE_COMPACTION_ENABLED;
+xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
+if ( cpu_has_xsaves || cpu_has_xsavec )
+xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
+ XSTATE_COMPACTION_ENABLED;
+}
 }
 else
-memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
+memset(v->arch.fpu_ctxt, 0, sizeof(ctxt.fpu_regs));
 
 v->arch.user_regs.eax = ctxt.rax;
 v->arch.user_regs.ebx = ctxt.rbx;
@@ -2125,7 +2142,6 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 v->arch.debugreg[7] = ctxt.dr7;
 
 v->arch.vgc_flags = VGCF_online;
-v->fpu_initialised = 1;
 
 /* Auxiliary processors should be woken immediately. */
 v->is_

Re: [Xen-devel] [PATCHv1] evtchn: don't reuse ports that are still "busy"

[Jan Beulich]

>>> On 30.11.15 at 18:59,  wrote:
> When using the FIFO ABI a guest may close an event channel that is
> still LINKED.  If this port is reused, subsequent events may be lost
> because they may become pending on the wrong queue.
> 
> This could be fixed by requiring guests to only close event channels
> that are not linked.  This is difficult since: a) irq cleanup in the
> guest may be done in a context that cannot wait for the event to be
> unlinked; b) the guest may attempt to rebind a PIRQ whose previous
> close is still pending; and c) existing guests already have the
> problematic behaviour.
> 
> Instead, simply check a port is not "busy" (i.e., it's not linked)
> before reusing it.

I agree with the reasoning, but see below.

> --- a/xen/common/event_2l.c
> +++ b/xen/common/event_2l.c
> @@ -74,6 +74,12 @@ static bool_t evtchn_2l_is_masked(struct domain *d,
>  return test_bit(evtchn->port, &shared_info(d, evtchn_mask));
>  }
>  
> +static bool_t evtchn_2l_is_busy(struct domain *d,
> +const struct evtchn *evtchn)
> +{
> +return 0;
> +}
> +
>  static void evtchn_2l_print_state(struct domain *d,
>const struct evtchn *evtchn)
>  {
> @@ -90,6 +96,7 @@ static const struct evtchn_port_ops evtchn_port_ops_2l =
>  .unmask= evtchn_2l_unmask,
>  .is_pending= evtchn_2l_is_pending,
>  .is_masked = evtchn_2l_is_masked,
> +.is_busy   = evtchn_2l_is_busy,
>  .print_state   = evtchn_2l_print_state,
>  };

Perhaps better to avoid introduction of the function by having the
wrapper check for NULL?

> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -170,7 +170,8 @@ static int get_free_port(struct domain *d)
>  {
>  if ( port > d->max_evtchn_port )
>  return -ENOSPC;
> -if ( evtchn_from_port(d, port)->state == ECS_FREE )
> +chn = evtchn_from_port(d, port);
> +if ( chn->state == ECS_FREE && !evtchn_port_is_busy(d, chn) )

Despite the reasonable arguments you give this looks very wrong:
How can a free port still be busy? Could we have a new ECS_* and
require guests to notify the hypervisor when they unlinked an
already closed port (while "close" would transition busy ports into
that new state)?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 1/9] xen/x86: set the vPMU interface based on the presence of a lapic

[Jan Beulich]

>>> On 30.11.15 at 21:28,  wrote:
> On 11/27/2015 08:42 AM, Roger Pau Monne wrote:
>> Instead of choosing the interface to expose to guests based on the guest
>> type, do it based on whether the guest has an emulated local apic or not.
>>
>> Signed-off-by: Roger Pau Monné 
>> Signed-off-by: Boris Ostrovsky 
>> Acked-by: Jan Beulich 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> ---
>> Changes since v8:
>>   - Don't add the xenpmu hypercalls to the HVM hypercall table (yet).
> 
> Without having the hypercalls available to HVMlite (?) guests these 
> changes, except possibly those in vmx.c/svm.c, are somewhat pointless 
> since we never reach patched code.
> 
> I understand desire not to increase size of hypercall tables which we 
> want to eventually get rid of but is it really worth doing (or rather 
> not doing) at the cost of not including useful functionality?

Considering that Konrad had designated you as (kind of informal)
PVH maintainer, perhaps this is a good reason for you to actually
do the folding now (and maybe we should record maintainership in
./MAINTAINERS even if there are no specific files to be listed)? In
any event, my ack was made dependent on the HVM hypercall
tables being left alone until folded, and I don't think I want to give
up on that.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle

[Wei Liu]

On Tue, Dec 01, 2015 at 12:16:42PM +, Lars Kurth wrote:
> 
> > On 11 Nov 2015, at 16:33, Wei Liu  wrote:
> > 
> > FWIW I think it would be valuable if we can CC some vendors /
> > contributors and get feedback from them.
> 
> I highlighted this at the Advisory Board meeting and the board is
> supportive. Concrete feedback was
>
> A) "I'm generally supportive of this because I believe it will help
> reduce ambiguities around the status of features and ultimately help
> improve quality." This was mirrored by everyone at the last meeting. 
>
> B) The preview vs. experimental classification was deemed to be a bit
> arbitrary, and maybe we can fold them into one category. The feeling
> was that the distinction does not provide much value and we should
> maybe come up with something simpler.
>
> C) A concern raised was that by being explicit about "legacy" features
> we may create negative PR opportunities, e.g. "the Xen Project has
> declared 50% of its features to be untested and undocumented". Perhaps
> instead we just grandfather these features into "stable" rather than
> having an explicit "legacy-stable" designation.
> 

Putting those into "stable" sounds reasonable to me. Plus some
clarification as you mentioned below.

> Another possible solution would be to be clear about what is
> automatically tested and what requires manual testing (or is currently
> tested by 3rd party test infrastructure such as XenRT and others) in
> the "Supported" category. The argument that can be made is that for
> "legacy-stable" we rely on 3rd party testing. This would help direct
> test resources during Test Days towards such features. 
> 
> The documentation angle is probably less of an issue, because we have
> user facing docs for pretty much everything in the man pages. So we
> basically mainly talk about specs and other documents which are either
> in the wiki or in docs/misc. And of course we can make judgement calls
> for those docs in pretty much the same way as we do now.
> 
> Any views on the pros and cons?
>  
> Lars

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] x86/VPMU: Support only versions 2 and 3 of architectural performance monitoring

[Jan Beulich]

>>> On 30.11.15 at 19:38,  wrote:
> ---
>  xen/arch/x86/cpu/vpmu_intel.c | 55 
> +++
>  1 file changed, 8 insertions(+), 47 deletions(-)

Considering the history of the file, I think the VMX maintainers
should be Cc-ed here. I think it was actually an oversight to change
maintainership of the files with their movement to xen/arch/x86/cpu/.

> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -955,59 +955,20 @@ int vmx_vpmu_initialise(struct vcpu *v)
>  int __init core2_vpmu_init(void)
>  {
>  u64 caps;
> +unsigned int version = 0;
>  
> -if ( current_cpu_data.x86 != 6 )
> +if ( current_cpu_data.cpuid_level >= 0xa )
> +version = cpuid_eax(0xa) & 0xff;

MASK_EXTR(cpuid_eax(0xa), PMU_VERSION_MASK)

> +if ( (version != 2) && (version != 3) )
>  {
> -printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
> +printk(XENLOG_WARNING "VPMU: version %d is not supported\n", 
> version);

%u

And I second Dietmar's request.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] x86/VPMU: No need to check whether VPMU quirk is needed on Intel

[Jan Beulich]

>>> On 30.11.15 at 19:38,  wrote:
> We only support family 6 so quirk handling is always needed.

Is that indeed the case for even the most modern CPUs?

In any event, Intel folks should be copied here too.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Emulating in response of an int3 vm_event

[Jan Beulich]

>>> On 01.12.15 at 11:51,  wrote:
> Jan: This is a good example of why unlikely regions should have
> symbols.  The stack trace from this bug is actively misleading because
> the symbol information for %eip is wrong.

And I didn't object to there being a single label put at the beginning
of the "unlikely" portion of a single source file. All I objected to was
putting labels at every contribution a source file may make.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Build problems with xen 4.7

[Jan Beulich]

>>> On 01.12.15 at 00:37,  wrote:
> When I try to build the current xen 4.7 master I get the following error
> 
> :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> :0:0: note: this is the location of the previous definition
> cc1: all warnings being treated as errors
> 
> The problem seems to be that -D__OBJECT_FILE__= is set each time 
> xen/Rules.mk is called, which happens more than once because of nested 
> makes resulting in multiple diffent values for -D__OBJECT_FILE__=

Considering you're the first one to have such a problem, I think the
precise compiler version you use matters here. Also the redundant
definitions shouldn't be different, and identical re-definition should
not yield a diagnostic. So I think there's a little more data you need
to supply in order to determine whether we need to adjust something.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Hotplugged devices in Xen 4.5 and domain reboot

[Pavlo Suikov]

Hi,

got a question regarding hotplugged devices in Xen 4.5. What we currently
have is Xen 4.5, Linux in Dom0 and DomD and Android in DomU. All the
devices are configured via domain config, so they are initialized on domain
startup: libxl reads config, sets up xenstore branches and fills them for
driver back ends and front ends; front ends monitor these branches and fill
in their specific data once connection is established. On DomU reboot,
config is being re-read and all the devices are started again in the same
manner.

Problem is we don't really know what to do with hotplugged devices. When
such a device appears in DomU during runtime, we set up all the xenstore
insformation on the fly, but it doesn't go to persistent domain
configuration; so when DomU reboot comes, they are not set up again as they
should. All the solutions we are considering look like dirty hacks (e.g.
making separate branch in xenstore for hotplugged devices, reading it on
domain start in the same way domain config is parsed, and copying data to
corresponding xenstore domain branches). Are there any existing ways to
handle these?

Suikov Pavlo
GlobalLogic
P +x.xxx.xxx.  M +38.066.667.1296  S psujkov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] public/sysctl: Clarifications to XEN_SYSCTL_PHYSCAP_hvm_directio

[Jan Beulich]

>>> On 01.12.15 at 12:37,  wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -89,7 +89,14 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_tbuf_op_t);
>   /* (x86) The platform supports HVM guests. */
>  #define _XEN_SYSCTL_PHYSCAP_hvm  0
>  #define XEN_SYSCTL_PHYSCAP_hvm   (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
> - /* (x86) The platform supports HVM-guest direct access to I/O devices. */
> + /*
> +  * (x86) The platform supports guest direct access to I/O devices.
> +  *
> +  * Note that this parameter has been misnamed since its introduction, and is
> +  * now too baked into APIs and ABIs to change.  Despite the "hvm" in its

What do you mean with "too baked into ..."? This is sysctl, which can
be changed, and I found just two uses (one in the hypervisor, the
other in libxl), so changing the use sites wouldn't seem all that
problematic (in the worst case we could also keep to current name
behind a __XEN_INTERFACE_VERSION__ conditional).

Jan

> +  * name, it simply indicates the presence of an enabled IOMMU, allowing for
> +  * passthrough of devices to guests, including PV guests.
> +  */
>  #define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
>  #define XEN_SYSCTL_PHYSCAP_hvm_directio  
> (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
>  struct xen_sysctl_physinfo {



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7 Development Update

[Yong Wang]

On Tue, Dec 01, 2015 at 11:54:54AM +, Lars Kurth wrote:
> Wei,
> and others.
> 
> > On 25 Nov 2015, at 02:17, Han, Huaitong  wrote:
> >> 
> >> = Projects =
> > 
> > == Hypervisor ==
> > === x86 ===
> > *Memory protection keys for user pages
> > -Huaitong Han
> 
> one thing I struggle with (and I am probably not the only one), is that it is 
> not always easy do find out what a specific patch does in the Development 
> Update mails. Obviously this is not an issue at the beginning of the cycle, 
> but it can become one when we start to put the release notes and PR together. 
> In this particular case, the use-case for the feature was described as a 
> one-liner else-where and I am wondering, whether we should allow tracking the 
> use/use-case/... in these mails.
> 
> Aka, in this case, using the information from the thread where the use-case 
> was discussed, will give us something like ...  
> 
> == Hypervisor ==
> === x86 ===
> * Memory protection keys for user pages
>   (allows threads to cooperatively prevent themselves from "trampling" on 
> each other, which increases robustness and is useful for debugging)
> - Huaitong Han
> 
> Part of the reason, why I am also looking at this, is because of the Feature 
> Lifecycle Management (see http://xen.markmail.org/message/uu3vifjmv2qylds4), 
> where we still have outstanding issues on documenting completed features. It 
> seems to me that there is an overlap between the Development Update mails, 
> and recording the state of an added feature in a central file. Obviously, if 
> a new feature was committed to xen.git, we would then need to add an entry to 
> the still to be defined central file describing it. And it would probably 
> make sense to keep the info in Development Update mails as close as possible 
> to what is in the still to be defined file.
> 
> Any thoughts?
> 

Isn't such information typically available in patch header (or patch 0 whatever 
you call it)? As developers start posting patches of the particular feature, 
can release manager add such info to the development update email if this can 
make Lars' life easier when he needs to compile such info for PR;-)

Thanks
-Yong


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 1/3] xsave: fix initialization of FPU memory area

[Andrew Cooper]

On 01/12/15 12:47, Roger Pau Monne wrote:
> When the CPU supports XSAVE, the initialization of the FPU memory area is
> done during allocation of the XSAVE area. This is different from the way
> it's done in non-xsave capable CPUs, so unify both paths and always
> initialise the FPU state in vcpu_restore_fpu_lazy.
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/i387.c   | 2 +-
>  xen/arch/x86/xstate.c | 8 
>  2 files changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
> index b661d39..fcd87a6 100644
> --- a/xen/arch/x86/i387.c
> +++ b/xen/arch/x86/i387.c
> @@ -226,7 +226,7 @@ void vcpu_restore_fpu_lazy(struct vcpu *v)
>  if ( v->fpu_dirtied )
>  return;
>  
> -if ( cpu_has_xsave )
> +if ( cpu_has_xsave && v->fpu_initialised )
>  fpu_xrstor(v, XSTATE_LAZY);
>  else if ( v->fpu_initialised )
>  fpu_fxrstor(v);

I feel this would be clearer if it were rearranged as

if ( v->fpu_initialised )
{
if ( cpu_has_xsave )
fpu_xrstor(v, XSTATE_LAZY);
else
{
...
}
}
else
fpu_init();


Functionally however, Reviewed-by: Andrew Cooper 

> diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
> index b65da38..8007342 100644
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -415,14 +415,6 @@ int xstate_alloc_save_area(struct vcpu *v)
>  if ( save_area == NULL )
>  return -ENOMEM;
>  
> -/*
> - * Set the memory image to default values, but don't force the context
> - * to be loaded from memory (i.e. keep save_area->xsave_hdr.xstate_bv
> - * clear).
> - */
> -save_area->fpu_sse.fcw = FCW_DEFAULT;
> -save_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
> -
>  v->arch.xsave_area = save_area;
>  v->arch.xcr0 = 0;
>  v->arch.xcr0_accum = 0;


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 2/3] xen/hvm: introduce a flags field in the CPU save record

[Andrew Cooper]

On 01/12/15 12:47, Roger Pau Monne wrote:
> Introduce a new flags field and use bit 0 to signal if the FPU has been
> initialised or not. Previously Xen always wrongly assumed the FPU was
> initialised on restore.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option

[Doug Goldstein]

On 12/1/15 4:44 AM, David Vrabel wrote:
> On 01/12/15 10:42, David Vrabel wrote:
>> On 30/11/15 21:35, Doug Goldstein wrote:
>>> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
>>> and /dev/xen/xenbus via pvops is used instead. This is an effort to
>>> eventually drop this interface after a reasonable amount of time.
>>
>> I would prefer the ... /proc/xen/evtchn files to be
> 
> I meant /proc/xen/privcmd here.
> 
> David
> 

I can look into that. I do have a few questions, some of which are out
of scope from the original patch.

Would it be preferable to just remove "xenbus" from the xenfs
filesystem? Ever since Linux 3.14 even if you are running a version of
Xen earlier than 4.6 you will not be able to have a disaggregated
xenstore (which is the xenbus consumer) due to the addition of F_ATOMIC_POS.

Is it safe for a kernel virtual filesystem to provide a symlink outside
of itself where the destination can't be verified? Its possible this
already exists and I just don't know off any cases off the top of my head.

Since the /proc/xen mount point has been marked as COMPAT for nearly 6
years would the eventual goal be to move xenfs to somewhere like
/sys/hypervisor given that most of the virtual filesystems are mounted
under /sys now days?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/2] libxl: change libxl__xs_mkdir() to libxl__xs_mknod()

[Paul Durrant]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 01 December 2015 12:37
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v2 0/2] libxl: change libxl__xs_mkdir() to
> libxl__xs_mknod()
> 
> On Wed, 2015-11-25 at 14:50 +, Paul Durrant wrote:
> > Patch #1 is purely a search and replace
> > Patch #2 changes the underlying implementation
> 
> Applied both.
> 

Thanks.

> I think these used to be part of "libxl: xenstore related cleanup", did
> this series completely replace that or are there still aspects yet to come
> and/or be reposted?
> 

I do have a couple more clean up patches to post. I should hopefully  be able 
to do that shortly.

  Paul

> 
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xen: wrap xenbus on xenfs with COMPAT option

[David Vrabel]

On 01/12/15 13:45, Doug Goldstein wrote:
> On 12/1/15 4:44 AM, David Vrabel wrote:
>> On 01/12/15 10:42, David Vrabel wrote:
>>> On 30/11/15 21:35, Doug Goldstein wrote:
 Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
 and /dev/xen/xenbus via pvops is used instead. This is an effort to
 eventually drop this interface after a reasonable amount of time.
>>>
>>> I would prefer the ... /proc/xen/evtchn files to be
>>
>> I meant /proc/xen/privcmd here.
>>
>> David
>>
> 
> I can look into that. I do have a few questions, some of which are out
> of scope from the original patch.
> 
> Would it be preferable to just remove "xenbus" from the xenfs
> filesystem? Ever since Linux 3.14 even if you are running a version of
> Xen earlier than 4.6 you will not be able to have a disaggregated
> xenstore (which is the xenbus consumer) due to the addition of F_ATOMIC_POS.

If /proc/xen/xenbus is made a symlink then older Xen toolstacks will
work again.

> Is it safe for a kernel virtual filesystem to provide a symlink outside
> of itself where the destination can't be verified?

Yes.  The symlink target is just a string containing a path.

> Since the /proc/xen mount point has been marked as COMPAT for nearly 6
> years would the eventual goal be to move xenfs to somewhere like
> /sys/hypervisor given that most of the virtual filesystems are mounted
> under /sys now days?

No. The information might move to /sys/hypervisor (or elsewhere) but
xenfs will always be mounted in /proc/xen (or not mounted at all).

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 1/2] libxl: re-name libxl__xs_write() to libxl__xs_printf()...

[Paul Durrant]

...to denote what it actually does.

The name libxl__xs_write() suggests something taking a buffer and length,
akin to write(2), whereas the semantics of the function are actually more
akin to printf(3).

This patch is a textual substitution of libxl__xs_write with
libxl__xs_printf with some associated formatting fixes.

Signed-off-by: Paul Durrant 
Acked-by: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl.c| 47 +-
 tools/libxl/libxl_bootloader.c |  4 ++--
 tools/libxl/libxl_create.c |  4 ++--
 tools/libxl/libxl_dm.c | 36 
 tools/libxl/libxl_dom.c| 23 +++--
 tools/libxl/libxl_exec.c   |  2 +-
 tools/libxl/libxl_genid.c  |  6 +++---
 tools/libxl/libxl_internal.h   |  4 ++--
 tools/libxl/libxl_pci.c| 22 ++--
 tools/libxl/libxl_qmp.c|  4 ++--
 tools/libxl/libxl_xshelp.c |  4 ++--
 11 files changed, 79 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bd3aac8..bd604ac 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1136,7 +1136,7 @@ int libxl__domain_pvcontrol_write(libxl__gc *gc, 
xs_transaction_t t,
 if (!shutdown_path)
 return ERROR_FAIL;
 
-return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
+return libxl__xs_printf(gc, t, shutdown_path, "%s", cmd);
 }
 
 static int libxl__domain_pvcontrol(libxl__gc *gc, uint32_t domid,
@@ -1364,7 +1364,7 @@ static void disk_eject_xswatch_callback(libxl__egc *egc, 
libxl__ev_xswatch *w,
 if (!value || strcmp(value,  "eject"))
 return;
 
-if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
+if (libxl__xs_printf(gc, XBT_NULL, wpath, "")) {
 LIBXL__EVENT_DISASTER(egc, "xs_write failed acknowledging eject",
   errno, LIBXL_EVENT_TYPE_DISK_EJECT);
 return;
@@ -4696,13 +4696,13 @@ retry_transaction:
 goto out;
 
 if (target == NULL) {
-libxl__xs_write(gc, t, target_path, "%"PRIu32,
-(uint32_t) info.current_memkb);
+libxl__xs_printf(gc, t, target_path, "%"PRIu32,
+ (uint32_t) info.current_memkb);
 *target_memkb = (uint32_t) info.current_memkb;
 }
 if (staticmax == NULL) {
-libxl__xs_write(gc, t, max_path, "%"PRIu32,
-(uint32_t) info.max_memkb);
+libxl__xs_printf(gc, t, max_path, "%"PRIu32,
+ (uint32_t) info.max_memkb);
 *max_memkb = (uint32_t) info.max_memkb;
 }
 
@@ -4839,8 +4839,8 @@ retry_transaction:
 goto out;
 }
 
-libxl__xs_write(gc, t, GCSPRINTF("%s/memory/target",
-dompath), "%"PRIu32, new_target_memkb);
+libxl__xs_printf(gc, t, GCSPRINTF("%s/memory/target", dompath),
+ "%"PRIu32, new_target_memkb);
 rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
 if (rc != 1 || info.domain != domid) {
 abort_transaction = 1;
@@ -4850,8 +4850,8 @@ retry_transaction:
 libxl_dominfo_init(&ptr);
 xcinfo2xlinfo(ctx, &info, &ptr);
 uuid = libxl__uuid2string(gc, ptr.uuid);
-libxl__xs_write(gc, t, GCSPRINTF("/vm/%s/memory", uuid),
-"%"PRIu32, new_target_memkb / 1024);
+libxl__xs_printf(gc, t, GCSPRINTF("/vm/%s/memory", uuid),
+ "%"PRIu32, new_target_memkb / 1024);
 libxl_dominfo_dispose(&ptr);
 
 out:
@@ -5486,9 +5486,9 @@ static int libxl__set_vcpuonline_xenstore(libxl__gc *gc, 
uint32_t domid,
 retry_transaction:
 t = xs_transaction_start(CTX->xsh);
 for (i = 0; i <= info->vcpu_max_id; i++)
-libxl__xs_write(gc, t,
-   GCSPRINTF("%s/cpu/%u/availability", dompath, i),
-   "%s", libxl_bitmap_test(cpumap, i) ? "online" : 
"offline");
+libxl__xs_printf(gc, t,
+ GCSPRINTF("%s/cpu/%u/availability", dompath, i),
+ "%s", libxl_bitmap_test(cpumap, i) ? "online" : 
"offline");
 if (!xs_transaction_end(CTX->xsh, t, 0)) {
 if (errno == EAGAIN)
 goto retry_transaction;
@@ -5984,7 +5984,8 @@ int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char 
sysrq)
 GC_INIT(ctx);
 char *dompath = libxl__xs_get_dompath(gc, domid);
 
-libxl__xs_write(gc, XBT_NULL, GCSPRINTF("%s/control/sysrq", dompath), 
"%c", sysrq);
+libxl__xs_printf(gc, XBT_NULL, GCSPRINTF("%s/control/sysrq", dompath),
+ "%c", sysrq);
 
 GC_FREE;
 return 0;
@@ -6262,12 +6263,12 @@ int libxl_cpupool_create(libxl_ctx *ctx, const char 
*name,
 t = xs_transaction_start(ctx->xsh);
 
 xs_mkdir(ctx->xsh, t, GCSPRINTF("/local/pool/%d", *poolid));
-libxl__xs_write(gc, t,
-GCSPRINTF("/local/pool/%d/uuid", *poolid),
-"%s", uuid_string);
-libxl__xs_write(gc, t,
- 

Re: [Xen-devel] [PATCH v5 1/3] xsave: fix initialization of FPU memory area

[Jan Beulich]

>>> On 01.12.15 at 14:39,  wrote:
> On 01/12/15 12:47, Roger Pau Monne wrote:
>> When the CPU supports XSAVE, the initialization of the FPU memory area is
>> done during allocation of the XSAVE area. This is different from the way
>> it's done in non-xsave capable CPUs, so unify both paths and always
>> initialise the FPU state in vcpu_restore_fpu_lazy.
>>
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> ---
>>  xen/arch/x86/i387.c   | 2 +-
>>  xen/arch/x86/xstate.c | 8 
>>  2 files changed, 1 insertion(+), 9 deletions(-)
>>
>> diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
>> index b661d39..fcd87a6 100644
>> --- a/xen/arch/x86/i387.c
>> +++ b/xen/arch/x86/i387.c
>> @@ -226,7 +226,7 @@ void vcpu_restore_fpu_lazy(struct vcpu *v)
>>  if ( v->fpu_dirtied )
>>  return;
>>  
>> -if ( cpu_has_xsave )
>> +if ( cpu_has_xsave && v->fpu_initialised )
>>  fpu_xrstor(v, XSTATE_LAZY);
>>  else if ( v->fpu_initialised )
>>  fpu_fxrstor(v);
> 
> I feel this would be clearer if it were rearranged as
> 
> if ( v->fpu_initialised )
> {
> if ( cpu_has_xsave )
> fpu_xrstor(v, XSTATE_LAZY);
> else
> {
> ...
> }
> }
> else
> fpu_init();

I agree, but would want this to then be done as

if ( !v->fpu_initialised )
fpu_init();
else if ( cpu_has_xsave )
fpu_xrstor(v, XSTATE_LAZY);
else
fpu_fxrstor(v);

(perhaps with an unlikely() on the first clause).

However, I'm unconvinced the change as a whole is correct:
XRSTOR initializes more than just FPU and MXCSR.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 2/2] libxl: re-implement libxl__xs_printf()

[Paul Durrant]

This patch adds a new libxl__xs_vprintf() which actually checks the
success of the underlying call to xs_write() (logging if it fails) and
then re-implements libxl__xs_printf() using this (and replacing the
call to vasprintf() with a call to libxl__vsprintf()).

libxl__xs_vprintf() is added to the 'checked' section of libxl_internal.h
and, since it now underpins libxl__xs_printf(), that declaration is
moved into the same section.

Looking at call sites of libxl__xs_printf() it seems as though several
of them expected a failure if the underlying xs_write() failed, so this
patch should actually fulfil the semantic that was intended all along.

Signed-off-by: Paul Durrant 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_internal.h |  8 +---
 tools/libxl/libxl_xshelp.c   | 32 ++--
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 12b2b30..e5000cf 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -666,9 +666,6 @@ _hidden int libxl__xs_writev_perms(libxl__gc *gc, 
xs_transaction_t t,
 /* _atonce creates a transaction and writes all keys at once */
 _hidden int libxl__xs_writev_atonce(libxl__gc *gc,
  const char *dir, char **kvs);
-
-_hidden int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
-   const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
/* Each fn returns 0 on success.
 * On error: returns -1, sets errno (no logging) */
 
@@ -688,6 +685,11 @@ _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t 
domid);
  * fails it logs and returns ERROR_FAIL.
  */
 
+int libxl__xs_vprintf(libxl__gc *gc, xs_transaction_t t,
+  const char *path, const char *fmt, va_list ap);
+int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
+ const char *path, const char *fmt, ...) 
PRINTF_ATTRIBUTE(4, 5);
+
 /* On success, path will exist and will be empty */
 int libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
 const char *path, struct xs_permissions *perms,
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 912a1f2..930b458 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -96,23 +96,35 @@ out:
 
 }
 
-int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
- const char *path, const char *fmt, ...)
+int libxl__xs_vprintf(libxl__gc *gc, xs_transaction_t t,
+  const char *path, const char *fmt, va_list ap)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
 char *s;
+bool ok;
+
+s = libxl__vsprintf(gc, fmt, ap);
+
+ok = xs_write(ctx->xsh, t, path, s, strlen(s));
+if (!ok) {
+LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, s);
+return ERROR_FAIL;
+}
+
+return 0;
+}
+
+int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
+ const char *path, const char *fmt, ...)
+{
 va_list ap;
-int ret;
+int rc;
+
 va_start(ap, fmt);
-ret = vasprintf(&s, fmt, ap);
+rc = libxl__xs_vprintf(gc, t, path, fmt, ap);
 va_end(ap);
 
-if (ret == -1) {
-return -1;
-}
-xs_write(ctx->xsh, t, path, s, ret);
-free(s);
-return 0;
+return rc;
 }
 
 char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 0/2] libxl: change libxl__xs_write() to libxl__xs_printf()

[Paul Durrant]

This is a re-post as I'd forgottent to add Cc-s for maintainers on patch #1

Patch #1 is purely a search and replace
Patch #2 changes the underlying implementation

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Hotplugged devices in Xen 4.5 and domain reboot

[Wei Liu]

On Tue, Dec 01, 2015 at 03:24:13PM +0200, Pavlo Suikov wrote:
> Hi,
> 
> got a question regarding hotplugged devices in Xen 4.5. What we currently
> have is Xen 4.5, Linux in Dom0 and DomD and Android in DomU. All the
> devices are configured via domain config, so they are initialized on domain
> startup: libxl reads config, sets up xenstore branches and fills them for
> driver back ends and front ends; front ends monitor these branches and fill
> in their specific data once connection is established. On DomU reboot,
> config is being re-read and all the devices are started again in the same
> manner.
> 
> Problem is we don't really know what to do with hotplugged devices. When
> such a device appears in DomU during runtime, we set up all the xenstore
> insformation on the fly, but it doesn't go to persistent domain
> configuration; so when DomU reboot comes, they are not set up again as they
> should. All the solutions we are considering look like dirty hacks (e.g.
> making separate branch in xenstore for hotplugged devices, reading it on
> domain start in the same way domain config is parsed, and copying data to
> corresponding xenstore domain branches). Are there any existing ways to
> handle these?
> 

Do you have the exact runes you use to do the hotplug? How do you reboot
your DomU? What does /var/lib/xen/userdata-d.$DOMID-$UUID.libxl-json
look like before and after hotplug?

Wei.

> Suikov Pavlo
> GlobalLogic
> P +x.xxx.xxx.  M +38.066.667.1296  S psujkov
> www.globallogic.com
> 
> http://www.globallogic.com/email_disclaimer.txt

> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1] evtchn: don't reuse ports that are still "busy"

[David Vrabel]

On 01/12/15 12:49, Jan Beulich wrote:
 On 30.11.15 at 18:59,  wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -170,7 +170,8 @@ static int get_free_port(struct domain *d)
>>  {
>>  if ( port > d->max_evtchn_port )
>>  return -ENOSPC;
>> -if ( evtchn_from_port(d, port)->state == ECS_FREE )
>> +chn = evtchn_from_port(d, port);
>> +if ( chn->state == ECS_FREE && !evtchn_port_is_busy(d, chn) )
> 
> Despite the reasonable arguments you give this looks very wrong:
> How can a free port still be busy? Could we have a new ECS_* and
> require guests to notify the hypervisor when they unlinked an
> already closed port (while "close" would transition busy ports into
> that new state)?

I would look at it as: The channel object is free, but the corresponding
ABI specific port object is busy.  So it doesn't seem unreasonable to
check the state of both objects.

What you suggest (adding an additional call) would break all existing
guests that would not make the unlinked call, leaving the event channel
in a state where it cannot be reused.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-snapshot test] 38405: regressions - FAIL

[Platform Team regression test user]

flight 38405 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38405/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
38328
 test-amd64-i386-amd64-current-netinst-pygrub 9 debian-di-install fail REGR. 
vs. 38328
 test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 
38328
 test-amd64-amd64-i386-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
38328
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 
38328
 test-amd64-amd64-amd64-weekly-netinst-pygrub 13 guest-saverestore fail REGR. 
vs. 38328

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail like 38328
 test-amd64-i386-amd64-weekly-netinst-pygrub 13 guest-saverestore fail like 
38328

baseline version:
 flight   38328

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  pass
 test-amd64-i386-i386-weekly-netinst-pygrub   pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxc: refactor memory allocation functions

[Juergen Gross]

On 01/12/15 13:12, Wei Liu wrote:
> On Tue, Dec 01, 2015 at 01:04:14PM +0100, Juergen Gross wrote:
>> On 01/12/15 12:58, Ian Campbell wrote:
>>> On Tue, 2015-12-01 at 11:39 +, Wei Liu wrote:
 There were some problems with the original memory allocation functions:
 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
 2. xc_dom_alloc_pad didn't call dom->allocate.

 Refactor the code so that:
 1. xc_dom_alloc_{segment,pad,page} end up calling
xc_dom_chk_alloc_pages.
 2. xc_dom_chk_alloc_pages calls dom->allocate.

 This way we avoid scattering dom->allocate over multiple locations and
 open-coding.

 Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
 an invalid pfn when xc_dom_chk_alloc_pages fails.
>>>
>>> Given this presumably the handful of callers ought to gain some error
>>> handling in a followup patch?
>>
>> I could do that. Wei?
>>
> 
> You're welcome to pick that up.
> 
>>>
>>> xc_dom_chk_alloc_pages does log, so at least the callers needn't bother
>>> with that.
>>>
 Signed-off-by: Wei Liu 
>>>
>>> Acked-by: Ian Campbell 
>>>
 ---
 Cc: Ian Campbell 
 Cc: Ian Jackson 
 Cc: Juergen Gross 

 We don't have INVALID_PFN, maybe we need one?
>>>
>>> We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the
>>> bill (or if not how it is distinct from the former).
>>
>> What about merging all of them into INVALID_FRAME?
>>
> 
> Note that INVALID_MFN is in public header (xenctrl.h) while
> INVALID_P2M_ENTRY is not.

INVALID_P2M_ENTRY in libxc is defined as (xen_pfn_t)-1. I think it
would make sense to modify that to INVALID_PFN.

> In fact (xen_pfn_t)-1 is part of guest ABI so we should properly export
> and document it. The current situation is not ideal. Not sure how much
> yak shaving is required though.

As this relates to the return value checking of the domain builder
memory allocating I'll have a try, too.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 65260: regressions - FAIL

[osstest service owner]

flight 65260 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65260/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 63340
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 63340

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  97c9ddefa13824b3f68bd4dd6d1456a4eb507f57
baseline version:
 libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95

Last test of basis63340  2015-10-28 04:19:47 Z   34 days
Failing since 63352  2015-10-29 04:20:29 Z   33 days   28 attempts
Testing same since65260  2015-11-30 15:29:36 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chen Hanxiao 
  Christian Loehle 
  Cole Robinson 
  Daniel P. Berrange 
  Daniel Veillard 
  Dmitry Andreev 
  Erik Skultety 
  Guido Günther 
  Jim Fehlig 
  Jiri Denemark 
  Joao Martins 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Marc-André Lureau 
  Martin Kletzander 
  Maxim Perevedentsev 
  Michal Privoznik 
  Michel Normand 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Richard Weinberger 
  Roman Bogorodskiy 
  Stefan Berger 
  Stefan Berger 
  Wei Jiangang 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  fail
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt blocked
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   blocked
 test-armhf-armhf-libvirt-raw blocked
 test-amd64-amd64-libvirt-vhd fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 2650 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 38406: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38406 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38406/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 8786ba4fe7220d24c41bf1386b7186eabda00a0c
baseline version:
 ovmf 81438fe8d0fc63f9bc9fcee0113baf6bd395f29c

Last test of basis38392  2015-11-30 14:20:34 Z1 days
Testing same since38406  2015-12-01 12:24:45 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Ruiyu Ni 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 8786ba4fe7220d24c41bf1386b7186eabda00a0c
Author: Ard Biesheuvel 
Date:   Mon Nov 30 08:57:26 2015 +

CryptoPkg/OpensslLib: add softfloat dependency for ARM

UEFI on 32-bit ARM does not allow the use of hardware floating point,
so in order to be able to run OpenSslLib, we need to fulfil its
floating point arithmetic dependencies using a software library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
Reviewed-by: Qin Long 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19033 
6f19259b-4bc3-4df7-8a09-765794883524

commit 2c9602443673d4e88c24e6c1ac78679b7d89c60f
Author: Ard Biesheuvel 
Date:   Mon Nov 30 08:57:12 2015 +

ArmVirtPkg: add secure boot support to 32-bit ARM targets

Building the 32-bit ARM targets with secure boot enabled requires
a library resolution for the ArmSoftfloatLib dependency of
OpenSslLib. So provide one.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Leif Lindholm 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19032 
6f19259b-4bc3-4df7-8a09-765794883524

commit c75f83719457fa0fc786b14c4ab8470da63cfeb3
Author: Ard Biesheuvel 
Date:   Mon Nov 30 08:57:03 2015 +

ArmPkg/ArmSoftFloatLib: add support for RVCT

The ARM softfloat library in ArmSoftfloatLib currently does not build
under RVCT, simply because the code includes system header files that
RVCT does not provide. However, nothing exported by those include files
is actually used by the library when built in SOFTFLOAT_FOR_GCC mode,
so we can just drop all of them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19031 
6f19259b-4bc3-4df7-8a09-765794883524

commit 1dbda2b4cfd60e5955cde98aec6537816af8be5e
Author: Ard Biesheuvel 
Date:   Mon Nov 30 08:56:52 2015 +

ArmPkg: factor out softfloat support from StdLib/LibC/SoftFloat

In order to support software floating point in the context of
DXE drivers etc, this factors out the core ARM softfloat support
into a separate library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19030 
6f19259b-4bc3-4df7-8a09-765794883524

commit cd32c66f94b44590053d79c45b8106ccc47ba247
Author: Dandan Bi 
Date:   Mon Nov 30 07:26:07 2015 +

MdeModulePkg:Replace unsafe string function with safe one.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19029 
6f19259b-4bc3-4df7-8a09-765794883524

commit 35ba063da8d7058c1650678d217b5c025255230d
Author: Yonghong Zhu 
Date:   Mon Nov 30 03:43:25 2015 +

BaseTools/toolsetup.bat: fixed the error w

Re: [Xen-devel] [PATCHv1] evtchn: don't reuse ports that are still "busy"

[Jan Beulich]

>>> On 01.12.15 at 15:04,  wrote:
> On 01/12/15 12:49, Jan Beulich wrote:
> On 30.11.15 at 18:59,  wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -170,7 +170,8 @@ static int get_free_port(struct domain *d)
>>>  {
>>>  if ( port > d->max_evtchn_port )
>>>  return -ENOSPC;
>>> -if ( evtchn_from_port(d, port)->state == ECS_FREE )
>>> +chn = evtchn_from_port(d, port);
>>> +if ( chn->state == ECS_FREE && !evtchn_port_is_busy(d, chn) )
>> 
>> Despite the reasonable arguments you give this looks very wrong:
>> How can a free port still be busy? Could we have a new ECS_* and
>> require guests to notify the hypervisor when they unlinked an
>> already closed port (while "close" would transition busy ports into
>> that new state)?
> 
> I would look at it as: The channel object is free, but the corresponding
> ABI specific port object is busy.  So it doesn't seem unreasonable to
> check the state of both objects.

While I think they're really tied together (namely due to how
get_free_port() works), yes - that's a way to view it, taking the
tying together as an implementation detail.

However, in that case it seems wrong to pass the channel pointer
to the is_busy() hook.

> What you suggest (adding an additional call) would break all existing
> guests that would not make the unlinked call, leaving the event channel
> in a state where it cannot be reused.

True.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On December 1, 2015 8:19:32 AM EST, Jan Beulich  wrote:
 On 01.12.15 at 00:37,  wrote:
>> When I try to build the current xen 4.7 master I get the following
>error
>> 
>> :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> :0:0: note: this is the location of the previous
>definition
>> cc1: all warnings being treated as errors
>> 
>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
>> xen/Rules.mk is called, which happens more than once because of
>nested 
>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
>
>Considering you're the first one to have such a problem, I think the
>precise compiler version you use matters here. Also the redundant
>definitions shouldn't be different, and identical re-definition should
>not yield a diagnostic. So I think there's a little more data you need
>to supply in order to determine whether we need to adjust something.
>

Ccing Marcos who also saw this. Marcos do you remember the git commit that 
caused this?


Thanks!
>Jan
>
>
>___
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/xen-devel



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] x86/VPMU: Support only versions 2 and 3 of architectural performance monitoring

[Boris Ostrovsky]

On 12/01/2015 04:01 AM, Dietmar Hahn wrote:

Am Montag 30 November 2015, 13:38:40 schrieb Boris Ostrovsky:

We need to have at least version 2 since it's the first version to
support various control and status registers (such as
MSR_CORE_PERF_GLOBAL_CTRL) that VPMU relies on always having.

With explicit testing for PMU version we can now remove CPUID model
check.

Signed-off-by: Boris Ostrovsky 
---
  xen/arch/x86/cpu/vpmu_intel.c | 55 +++
  1 file changed, 8 insertions(+), 47 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index d5ea7fe..bb4ddcc 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -955,59 +955,20 @@ int vmx_vpmu_initialise(struct vcpu *v)
  int __init core2_vpmu_init(void)
  {
  u64 caps;
+unsigned int version = 0;
  
-if ( current_cpu_data.x86 != 6 )

+if ( current_cpu_data.cpuid_level >= 0xa )
+version = cpuid_eax(0xa) & 0xff;
+if ( (version != 2) && (version != 3) )
  {
-printk(XENLOG_WARNING "VPMU: only family 6 is supported\n");
+printk(XENLOG_WARNING "VPMU: version %d is not supported\n", version);
  return -EINVAL;

But this means that all (newer?) processors with version=4 are not supported
even though the SDM 3B tells:
"Processors supporting architectural performance monitoring version 4 also
  supports version 1, 2, and 3, ..."

Shold we not only write a hint that version 4 capabilities are not supported
and fake this cpuid-flag for the guests to the version 3?


I in fact didn't know there was version 4 since I've always been looking 
at (apparently) old version of the SDM (Jan 2013).


We should indeed then downgrade version 4 to 3 as reported by .do_cpud() op.

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxl: Be more careful with error handling in libxl__dm_runas_helper()

[Ian Campbell]

On Mon, 2015-11-30 at 13:24 -0500, Boris Ostrovsky wrote:
>      root@orochi-c> cat /etc/redhat-release
>  Fedora release 20 (Heisenbug)
>  root@orochi-c> ./a.out foobar
>  s = 2 errno = 2 result = (nil)
>  getpwnam_r: No such file or directory
>  root@orochi-c>
> 
> which does look like a bug in F20 since the code above is taken from man 
> pages' EXAMPLE and doesn't look like it works as intended (which was to 
> produce "Not found" string)

https://bugzilla.redhat.com/show_bug.cgi?id=988068 seems related (although
is blaming "sssd" rather than glibc it seems).

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 9p file system for xen

[Linda]

On 12/1/2015 4:47 AM, Wei Liu wrote:

On Mon, Nov 30, 2015 at 12:19:18PM -0500, Neil Sikka wrote:

Hi Wei, could you please explain why/how you would have done the project
differently now and why these patches are not "good"? From my conversation
with Linda, I understood that her code is "Independent of virtio except the
9pvirtio specific code, which is used extensively."


I need to implement a xen transport for 9pfs. Linda was essentially
doing the same. But she didn't specify the canonical protocol between
frontend and backend.
For my own edification:  In the interests of the limited time of my 
internship, we decided I shouldn't do the initialization using the xen 
toolstack.  Were there are other expediencies that I'm unaware of?


I tried to follow the xen handshaking protocol between front and back 
end at startup.


Thanks.

Linda


As for "9pvirtio specific code", I think there is misunderstanding
because though a lot of files in QEMU are prefixed with virtio they are
actually not specific to virtio at all. I think the "independent of
virtio ..." part was referring to the new transport she wrote.

Wei.




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] 9p file system for xen

[Wei Liu]

On Tue, Dec 01, 2015 at 07:37:43AM -0700, Linda wrote:
> 
> 
> On 12/1/2015 4:47 AM, Wei Liu wrote:
> >On Mon, Nov 30, 2015 at 12:19:18PM -0500, Neil Sikka wrote:
> >>Hi Wei, could you please explain why/how you would have done the project
> >>differently now and why these patches are not "good"? From my conversation
> >>with Linda, I understood that her code is "Independent of virtio except the
> >>9pvirtio specific code, which is used extensively."
> >>
> >I need to implement a xen transport for 9pfs. Linda was essentially
> >doing the same. But she didn't specify the canonical protocol between
> >frontend and backend.
> For my own edification:  In the interests of the limited time of my
> internship, we decided I shouldn't do the initialization using the xen
> toolstack.  Were there are other expediencies that I'm unaware of?
> 

It's not about toolstack. Toolstack merely sets up xenstore nodes
according to the protocol.

> I tried to follow the xen handshaking protocol between front and back end at
> startup.
> 

Yes, that's the right direction. Following existing convention is good
enough for an intern project. Specifying the protocol in detailed is not
the requirement for a prototype.

But in the end to upstream xen-9pfs a canonical protocol is required.  A
blessed version of protocol needs to be committed to xen.git tree.  We
have a bunch of those in xen.git/xen/include/public/io/ directory.

Wei.

> Thanks.
> 
> Linda
> >
> >As for "9pvirtio specific code", I think there is misunderstanding
> >because though a lot of files in QEMU are prefixed with virtio they are
> >actually not specific to virtio at all. I think the "independent of
> >virtio ..." part was referring to the new transport she wrote.
> >
> >Wei.
> >
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Build problems with xen 4.7

[M A Young]

On Tue, 1 Dec 2015, Jan Beulich wrote:

> >>> On 01.12.15 at 00:37,  wrote:
> > When I try to build the current xen 4.7 master I get the following error
> > 
> > :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > :0:0: note: this is the location of the previous definition
> > cc1: all warnings being treated as errors
> > 
> > The problem seems to be that -D__OBJECT_FILE__= is set each time 
> > xen/Rules.mk is called, which happens more than once because of nested 
> > makes resulting in multiple diffent values for -D__OBJECT_FILE__=
> 
> Considering you're the first one to have such a problem, I think the
> precise compiler version you use matters here. Also the redundant
> definitions shouldn't be different, and identical re-definition should
> not yield a diagnostic. So I think there's a little more data you need
> to supply in order to determine whether we need to adjust something.

This is just with Fedora's gcc-5.1.1-4.fc23.x86_64 with the standard 
package build options, including -Werror . The values of 
-D__OBJECT_FILE__= really are different, with (from memory) the first 
being the absolute path to the /xen subdirectory of the unpacked xen-4.7 
source and the second a relative path to the file being complied from 
there.

Michael Young

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel