Xen 4.5 development update (July update)

Xen 4.5 development update (July update)

[konrad.wilk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 11782 bytes --]

Below is a summary of the projects / features being worked on for the 4.5
time frame.  The tentative feature freeze is scheduled for September 10th,
which is two months away. This being the summer some folks are talking
vacation, so those two months might be a lot less.

The "prognosis" is now the likelihood of completion in the 4.5 timeframe.
A bunch of items had moved to the completed phase which is fantastic.

However we still have some that are important but the code hadn't yet
been posted which is worrisome. I've also moved some to Xen 4.6 after
talking with folks privately.

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs

For items involving code hosted on the Xen.org site (including qemu-xen),
that means a likelihood of having the feature code-complete and mostly
working by the feature freeze.  (It's OK if there are still bugs to be
worked out.)  For items in Linux, it would mean having items on track
to make it into the kernel released just after the scheduled 4.5 time frame.

In terms of libvirt it has monthly releases. As such not going to track
every release - but closer to when RCs are out.

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:

* Coding time: <=== NOW, two months left!

* Feature Freeze: 10th September 2014
* First RC: 10th October
* Release: 10th December 2014

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

= Prognosis =

The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs


= Open =

== ARM ==

*  ARM - Device assigment on ARM (good)
   RFC for the hypervisor side sent.
   Linux parts at risk.
  -  Julien Grall

*  ARM XEN_DOMCTL_memory_mapping hypercall for ARM (good)
   v9 posted; resent & rebased
  -  Arianna Avanzini

*  ARM Xen UEFI booting on ARM (ok)
   v2
  -  Roy Franz

*  ARM PSCI v0.2 (good)
   v3 posted
  -  Parth Dixit

*  ARM GICv3 support (ok)
   v6a patchset (refactor in, also known as v9a); v7 posted
   v9a posted which does GIC and VGIC code refactoring
  -  Vijay Kilari

*  ARM VM save/restore/live migration (ok)
  -  Junghyun Yoo

*  ARM remote processor iommu module (GPUs + IPUs) (unknown)
  -  Andrii Tseglytskyi

*  ARM: Use super pages in p2m (ok)
   v5 posted
  -  Ian Campbell

*  ARM - MiniOS (ok)
   v6 posted
  -  Thomas Leonard

*  ARM - VGIC emulation (ok)
   v8
  -  Stefano Stabellini

*  ARM - XENFEAT_grant_map_11 (fair)
   Provide kernels an grant->MFN lookup
   RFC
  -  Stefano Stabellini

== x86 ==

*  New Migration (v2). (ok)
   v6 posted
   libxl is next
   tmem & remus need work
  -  Andrew Cooper & David Vrabel

*  Remus using migration-v2 (fair)
   RFC posted - depends on v6 of 'New Migration'
  -  Yang Hongyang

*  PVH - AMD hardware support. (fair)
   Issues with FSBASE MSRs
  -  Mukesh Rathor

*  Xen multiboot2-EFI support (fair)
   Needed for SecureBoot
   Depends on Xen Boot info (rework multiboot and other structs)
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
  -  Daniel Kiper

*  Xen HPET interrupt fixes (fair)
   behind migration v2
  -  Andrew Cooper

*  HT enabled, virtualization overhead is high (Xen 4.4) (none)
   kernbench demonstrated it
   looking and tracing it
  -  Dario Faggioli

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  dirty vram / IOMMU bug (fair)
  -  Zhang, Yang Z

*  Convert tasklet to per-cpu tasklets (fair)
  -  Konrad Rzeszutek Wilk

*  VMware backdoor (hypercall) (ok)
   Needs to be split up and redone
  -  Don Slutz

*  VPMU - 'perf' support in Xen (good)
   v8 posted
  -  Boris Ostrovsky

*  Cache QoS Monitoring - hypercalls (fair)
   Just hypercalls - no toolstack changes.
   v12 posted
  -  Dongxiao Xu and Shantong Kang

*  1TB slow destruction (ok)
  -  Bob Liu

*  extending mem_access support to PV domain (fair)
   RFC v2
  -  Aravindh Puthiyaparambil (aravindp)

*  Stability fix (good)
  -  Jan Beulich

*  Support controlling the max C-state sub-state (ok)
   v3 posted
  -  Ross Lagerwall

*  Repurpose SEDF Scheduler for Real-time (fair)
   RFC patch posted (v2)
  -  Joshua Whitehead, Robert VanVossen

*  XenRT (Preemptive Global Earliest Deadline First) (fair)
   RFC patch posted (v1)
  -  Meng Xu

*  Introspection of HVM guests (fair)
   RFC v2
  -  Razvan Cojocaru

*  vNUMA in Xen (ok)
   v6 posted
   git://gitorious.org/vnuma/xen_vnuma.git
  -  Elena Ufimtseva

== QEMU ==

*  Rebase of QEMU 2.0 and SeaBIOS (fair)
  -  Ian Jackson

*  Using qemu-upstream in a stubdomain (fair)
   Will use rump kernels.
  -  Ian Jackson

*  Intel IGD PCI GPU passthrough (ok)
   v5 posted
  -  Chen, Tiejun

*  Xen PV block driver in OVMF (UEFI in guest) (fair)
   RFC posted.
  -  Anthony PERARD

== lib{xc,xl} and toolstack ==

*  libxl/xl - xm compatibility mode for mem-max and mem-set; (ok)
  -  Daniel Kiper

*  Rearrange and cleanup installation destination directories (/var -> var/lib/xen) (fair)
  -  Daniel Kiper

*  libxl work - JSON to keep track of guest configs (ok)
  -  Wei Liu

*  pvscsi should be targeted for 4.5, a prototype exists (fair)
  -  Olaf Hering

*  xl list --long (and some related xl commands) have some bugs (none)
  -  Zhigang Wang

*  Remus in Xen (libxl) (ok)
   v17
   url: https://github.com/laijs/xen remus-v17
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  COarse-grain LOck-stepping Virtual Machines in Xen (fair)
   RFC patch posted
  -  Wen Congyang
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  systemd support (ok)
   v7
  -  Luis R. Rodriguez

*  snapshot API extension (checkpointing disk) (ok)
   v5
  -  Bamvor Jian Zhang

*  extend the xenstore ring with a 'closing' signal (fair)
   RFC patch posted
  -  David Scott

*  Soft affinity for vcpus libxl/xl changes (good)
   v12 posted
  -  Dario Faggioli

== Linux ==

*  Linux block multiqueue (fair)
  -  Arianna Avanzini

*  Netback grant table manipulations (ok)
  -  Zoltan Kiss

*  VPMU - 'perf' support in Linux (ok)
   Depends on Xen patches
  -  Boris Ostrovsky

*  vNUMA in Linux (ok)
   v6 posted
   git://gitorious.org/vnuma/linux_vnuma.git
  -  Elena Ufimtseva

*  vsyscall in Linux (fair)
  -  Konrad Rzeszutek Wilk

*  COLO Agent in Linux (fair)
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  vAPIC in PVHVM guests (Linux side) (none)
  -  Boris Ostrovsky

*  pvSCSI (ok)
   Initial patch posted.
  -  Juergen Gross

== FreeBSD ==

*  PVH FreeBSD dom0 (ok)
   FreeBSD 11 goal. Toolstack side done in Xen 4.5
  -  Roger Pau Monné

== Other OSes (MiniOS, QNX) ==

*  PV drivers for automotive kernels (fair)
  -  Artem Mygaiev

*  mini-os: xenbus changes for rump kernels (ok)
   git://xenbits.xen.org/people/iwj/rumpuser-xen.git
   branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
   v2 posted
  -  Ian Jackson

== GRUB2 ==

*  GRUB2 multiboot2 (fair)
  -  Daniel Kiper

== OSSTEST ==

*  OSSTest: libvirt (good)
  -  Ian Campbell

== Deferred to Xen 4.6 ==

*  Default to credit2 (none)
   cpu pinning, numa affinity and cpu reservation
  -  George Dunlap

*  "Short" grant copy (just header) of packets. (none)
  -  Zoltan Kiss

*  cpuid leveling (none)
   http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
  -  Andrew Cooper

*  live migration knobs, there is no suitable code yet, just ideas (none)
    http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html
  -  Olaf Hering

*  Further tmem cleanups/fixes (16TB etc) (fair)
  -  Bob Liu

*  IO-NUMA - hwloc and xl (fair)
   Andrew Cooper had an RFC patch for hwloc
  -  Boris Ostrovsky

*  AMD Radeon PCI GPU passthrough (none)
   Focusing on Xen 4.2 and qemu-traditional
  -  Kelly Zytaruk

*  xl does not handle migrate interruption gracefully (none)
   If you start a localhost migrate, and press "Ctrl-C" in the middle, you get two hung domains
  -  Ian Jackson

*  HVM guest NUMA (none)
  -  Matt Wilson

*  PVH - Migration of PVH DomUs. (none)
   Depends on migration2 code
  -  Roger Pau Monné

*  PVH - Migration of guests from a PVH dom0  (none)
   Depends on migration2 code
  -  Roger Pau Monné

*  ARM GICv2m support (none)
  -  Linaro (unknown)

== Up for grabs ==

*  OSSTest - also test Linux PVH guests

*  PoD fixes
   if you boot with memory <= maxmem we have a size estimation bug

*  TLB flushing without locks in Xen

*  xl does not support specifying virtual function for passthrough device
   http://bugs.xenproject.org/xen/bug/22

*  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
   http://bugs.xenproject.org/xen/bug/28

*  libx{c,l} error handling cleanup

*  Adding missing 'xend' features in libxl

*  xl list -l on a dom0-only system

*  xl list -l doesn't contain tty console port

*  xl: passing more defaults in configuration in xl.conf
   There are a number of options for which it might be useful to pass a default in xl.conf.  For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0.

*  PVH - PVH working with shadow.
   Based on Tim's work

*  PVH - PCI passthrough for DomU.

*  AMD performance regressions

*  Performance due to hypercall preemption. More preemptions - slower. (none)

== Completed ==

*  alternative_asm in Xen (done)
  -  Feng Wu

*  SMAP (done)
  -  Feng Wu

*  Re-write of vHPET (done)
   aka hvm/hpet: Detect comparator values in the past
  -  Don Slutz

*  vAPIC in PVHVM guests (Xen side) (done)
  -  Boris Ostrovsky

*  libvirt and xl discard support, so that libvirt can start using it (done)
  -  Olaf Hering

*  Xen PVH dom0 (done)
  -  Mukesh Rathor

*  Linux PVH dom0 (done)
  -  Mukesh Rathor

*  OSSTest: upstream QEMU (done)
  -  Ian Campbell

*  amd_ucode cleanups, verify patch size(enhancement) (mostly in master except one patch)

*  Data breakpoint Extension support (new-feat) (in master)

*  Feature masking MSR support (enhancement) (in master)

*  Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in master)

*  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cleanups)
  -  Aravind and Suravee

*  NUMA memory scrubbing (done)
  -  Konrad Rzeszutek Wilk

*  ARM  - IOMMU support (done)
  -  Julien Grall

*  ioreq-server, aka secondary emulators (done)
  -  Paul Durrant

*  Netback multiqueue (good)
  -  Wei Liu

*  ARM Interrupt latency reduction (no maintenance interrupts) (good)
  -  Stefano Stabellini

*  Bigger PCI hole in QEMU (done)
   Needs to be rebased
  -  Don Slutz

*  ARM DRA7 support (done)
   v3 posted
   v3 with comments applied
  -  Andrii Tseglytskyi

*  rework VM Generation ID (done)
   v7 posted
  -  David Vrabel

*  Soft affinity for vcpus (was NUMA affinity for vcpus) (good)
   v11 posted
  -  Dario Faggioli

*  Linux pvops of Xen EFI hypercall support (done)
  -  Daniel Kiper



[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.5 development update (July update)

[Boris Ostrovsky]

On 07/22/2014 08:28 PM, konrad.wilk@oracle.com wrote:
>
> *  IO-NUMA - hwloc and xl (fair)
>     Andrew Cooper had an RFC patch for hwloc
>    -  Boris Ostrovsky


I don't think we ever planned this for 4.5. This is a "none".

-boris

Re: Xen 4.5 development update (July update)

[Andrew Cooper]

On 23/07/2014 01:28, konrad.wilk@oracle.com wrote:
> Below is a summary of the projects / features being worked on for the 4.5
> time frame.  The tentative feature freeze is scheduled for September 10th,
> which is two months away. This being the summer some folks are talking
> vacation, so those two months might be a lot less.
>
> The "prognosis" is now the likelihood of completion in the 4.5 timeframe.
> A bunch of items had moved to the completed phase which is fantastic.
>
> However we still have some that are important but the code hadn't yet
> been posted which is worrisome. I've also moved some to Xen 4.6 after
> talking with folks privately.
>
> none - nothing yet
> fair - still working on it, patches are prototypes or RFC
> ok   - patches posted, acting on review
> good - some last minute pieces
> done - all done, might have bugs
>
> For items involving code hosted on the Xen.org site (including qemu-xen),
> that means a likelihood of having the feature code-complete and mostly
> working by the feature freeze.  (It's OK if there are still bugs to be
> worked out.)  For items in Linux, it would mean having items on track
> to make it into the kernel released just after the scheduled 4.5 time frame.
>
> In terms of libvirt it has monthly releases. As such not going to track
> every release - but closer to when RCs are out.
>
> = Timeline =
>
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
>
> * Coding time: <=== NOW, two months left!
>
> * Feature Freeze: 10th September 2014
> * First RC: 10th October
> * Release: 10th December 2014
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
>
> = Prognosis =
>
> The states are: none -> fair -> ok -> good -> done
>
> none - nothing yet
> fair - still working on it, patches are prototypes or RFC
> ok   - patches posted, acting on review
> good - some last minute pieces
> done - all done, might have bugs
>
>
> = Open =
>
> <snip>
>
> == x86 == 
>
> *  New Migration (v2). (ok)
>    v6 posted
>    libxl is next
>    tmem & remus need work
>   -  Andrew Cooper & David Vrabel

remus should be removed from this section as it now has its own section
below.

I think the libxl work should also be split out, which is currently
'none'.  The libxc work is 'ok' going on 'good' (but still probably on
the ok side).

~Andrew

Re: Xen 4.5 development update (July update)

[Ian Campbell]

(trimming CC to just those related to things I've commented on)

On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:

> fair - still working on it, patches are prototypes or RFC

You've used this (correctly per your definition here) on various things
which it seems to me are very unlikely to make it for 4.5, i.e. things
which are really early prototypes etc, which made me pause every time I
ready it and have to think back to the definition.

I guess what I'm saying is that "fair" is not a good label for this
state, it implies that while the thing is a WIP it is still likely to
make it for 4.5.

I think you need a lower ranked WIP label for things which are in that
state of prototype/RFC but not likely to make 4.5. "wip" or "inprogress"
perhaps.

> = Open =
> 
> == ARM == 
[...]

> *  ARM VM save/restore/live migration (ok)
>   -  Junghyun Yoo

I've not heard from Junghyun since the initial reposting, not sure what
the prognosis is but given lack of support for SMP and some of the other
issues I'm more incline to suggest fair rather than OK. Jinghyun, do you
have any thoughts?

It's possible that the "save/restore/dead-migration" bit is "ok", it's
the live migration bits where the issues mostly remain iffy.

Also this is dependent on the migration v2 by Andrew et al.

> *  ARM: Use super pages in p2m (ok)
>    v5 posted
>   -  Ian Campbell

Committed.

> == QEMU == 
> 
> *  Rebase of QEMU 2.0 and SeaBIOS (fair)
>   -  Ian Jackson

What is this? Neither of them sound like Ian J things. Stefano maintains
Qemu and I take care of SeaBIOS.

>From the SeaBIOS side we are currently using the latest upstream.

IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
with, but he should confirm...

Ian.

Re: Xen 4.5 development update (July update)

[Stefano Stabellini]

On Wed, 23 Jul 2014, Ian Campbell wrote:
> (trimming CC to just those related to things I've commented on)
> 
> On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
> 
> > fair - still working on it, patches are prototypes or RFC
> 
> You've used this (correctly per your definition here) on various things
> which it seems to me are very unlikely to make it for 4.5, i.e. things
> which are really early prototypes etc, which made me pause every time I
> ready it and have to think back to the definition.
> 
> I guess what I'm saying is that "fair" is not a good label for this
> state, it implies that while the thing is a WIP it is still likely to
> make it for 4.5.
> 
> I think you need a lower ranked WIP label for things which are in that
> state of prototype/RFC but not likely to make 4.5. "wip" or "inprogress"
> perhaps.
> 
> > = Open =
> > 
> > == ARM == 
> [...]
> 
> > *  ARM VM save/restore/live migration (ok)
> >   -  Junghyun Yoo
> 
> I've not heard from Junghyun since the initial reposting, not sure what
> the prognosis is but given lack of support for SMP and some of the other
> issues I'm more incline to suggest fair rather than OK. Jinghyun, do you
> have any thoughts?
> 
> It's possible that the "save/restore/dead-migration" bit is "ok", it's
> the live migration bits where the issues mostly remain iffy.
> 
> Also this is dependent on the migration v2 by Andrew et al.
> 
> > *  ARM: Use super pages in p2m (ok)
> >    v5 posted
> >   -  Ian Campbell
> 
> Committed.
> 
> > == QEMU == 
> > 
> > *  Rebase of QEMU 2.0 and SeaBIOS (fair)
> >   -  Ian Jackson
> 
> What is this? Neither of them sound like Ian J things. Stefano maintains
> Qemu and I take care of SeaBIOS.

Yeah, it should be me for QEMU and it is done.


> >From the SeaBIOS side we are currently using the latest upstream.
> 
> IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
> with, but he should confirm...

Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
again a new QEMU upstream release before 4.5.

Re: Xen 4.5 development update (July update)

[Don Slutz]

On 07/23/14 06:20, Stefano Stabellini wrote:
> On Wed, 23 Jul 2014, Ian Campbell wrote:
>> (trimming CC to just those related to things I've commented on)
>>
>> On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
>>

>>> == QEMU ==
>>>
>>> *  Rebase of QEMU 2.0 and SeaBIOS (fair)
>>>    -  Ian Jackson
>> What is this? Neither of them sound like Ian J things. Stefano maintains
>> Qemu and I take care of SeaBIOS.
> Yeah, it should be me for QEMU and it is done.
>
>
>> >From the SeaBIOS side we are currently using the latest upstream.
>>
>> IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
>> with, but he should confirm...
> Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> again a new QEMU upstream release before 4.5.
>

Based on this,

Message-ID: <1405424067-23136-1-git-send-email-dslutz@verizon.com>
http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01923.html

Needs to wait for 4.6
     -Don Slutz




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

Re: Xen 4.5 development update (July update)

[Stefano Stabellini]

On Wed, 23 Jul 2014, Don Slutz wrote:
> On 07/23/14 06:20, Stefano Stabellini wrote:
> > On Wed, 23 Jul 2014, Ian Campbell wrote:
> > > (trimming CC to just those related to things I've commented on)
> > > 
> > > On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
> > > 
> 
> > > > == QEMU ==
> > > > 
> > > > *  Rebase of QEMU 2.0 and SeaBIOS (fair)
> > > >    -  Ian Jackson
> > > What is this? Neither of them sound like Ian J things. Stefano maintains
> > > Qemu and I take care of SeaBIOS.
> > Yeah, it should be me for QEMU and it is done.
> > 
> > 
> > > >From the SeaBIOS side we are currently using the latest upstream.
> > > 
> > > IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
> > > with, but he should confirm...
> > Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> > again a new QEMU upstream release before 4.5.
> > 
> 
> Based on this,
> 
> Message-ID: <1405424067-23136-1-git-send-email-dslutz@verizon.com>
> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01923.html
> 
> Needs to wait for 4.6
>     -Don Slutz

I would be happy to backport that patch once it is upstream.

Re: Xen 4.5 development update (July update)

[Fabio Fantoni]

Il 23/07/2014 12:20, Stefano Stabellini ha scritto:
> On Wed, 23 Jul 2014, Ian Campbell wrote:
>> (trimming CC to just those related to things I've commented on)
>>
>> On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
>>
>>> fair - still working on it, patches are prototypes or RFC
>> You've used this (correctly per your definition here) on various things
>> which it seems to me are very unlikely to make it for 4.5, i.e. things
>> which are really early prototypes etc, which made me pause every time I
>> ready it and have to think back to the definition.
>>
>> I guess what I'm saying is that "fair" is not a good label for this
>> state, it implies that while the thing is a WIP it is still likely to
>> make it for 4.5.
>>
>> I think you need a lower ranked WIP label for things which are in that
>> state of prototype/RFC but not likely to make 4.5. "wip" or "inprogress"
>> perhaps.
>>
>>> = Open =
>>>
>>> == ARM ==
>> [...]
>>
>>> *  ARM VM save/restore/live migration (ok)
>>>    -  Junghyun Yoo
>> I've not heard from Junghyun since the initial reposting, not sure what
>> the prognosis is but given lack of support for SMP and some of the other
>> issues I'm more incline to suggest fair rather than OK. Jinghyun, do you
>> have any thoughts?
>>
>> It's possible that the "save/restore/dead-migration" bit is "ok", it's
>> the live migration bits where the issues mostly remain iffy.
>>
>> Also this is dependent on the migration v2 by Andrew et al.
>>
>>> *  ARM: Use super pages in p2m (ok)
>>>     v5 posted
>>>    -  Ian Campbell
>> Committed.
>>
>>> == QEMU ==
>>>
>>> *  Rebase of QEMU 2.0 and SeaBIOS (fair)
>>>    -  Ian Jackson
>> What is this? Neither of them sound like Ian J things. Stefano maintains
>> Qemu and I take care of SeaBIOS.
> Yeah, it should be me for QEMU and it is done.
>
>
>> >From the SeaBIOS side we are currently using the latest upstream.
>>
>> IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
>> with, but he should confirm...
> Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> again a new QEMU upstream release before 4.5.

qemu 2.1 is near to be released, now is rc3, why not update to 2.1?

thanks for any reply

Re: Xen 4.5 development update (July update)

[Stefano Stabellini]

On Wed, 23 Jul 2014, Fabio Fantoni wrote:
> Il 23/07/2014 12:20, Stefano Stabellini ha scritto:
> > On Wed, 23 Jul 2014, Ian Campbell wrote:
> > > (trimming CC to just those related to things I've commented on)
> > > 
> > > On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
> > > 
> > > > fair - still working on it, patches are prototypes or RFC
> > > You've used this (correctly per your definition here) on various things
> > > which it seems to me are very unlikely to make it for 4.5, i.e. things
> > > which are really early prototypes etc, which made me pause every time I
> > > ready it and have to think back to the definition.
> > > 
> > > I guess what I'm saying is that "fair" is not a good label for this
> > > state, it implies that while the thing is a WIP it is still likely to
> > > make it for 4.5.
> > > 
> > > I think you need a lower ranked WIP label for things which are in that
> > > state of prototype/RFC but not likely to make 4.5. "wip" or "inprogress"
> > > perhaps.
> > > 
> > > > = Open =
> > > > 
> > > > == ARM ==
> > > [...]
> > > 
> > > > *  ARM VM save/restore/live migration (ok)
> > > >    -  Junghyun Yoo
> > > I've not heard from Junghyun since the initial reposting, not sure what
> > > the prognosis is but given lack of support for SMP and some of the other
> > > issues I'm more incline to suggest fair rather than OK. Jinghyun, do you
> > > have any thoughts?
> > > 
> > > It's possible that the "save/restore/dead-migration" bit is "ok", it's
> > > the live migration bits where the issues mostly remain iffy.
> > > 
> > > Also this is dependent on the migration v2 by Andrew et al.
> > > 
> > > > *  ARM: Use super pages in p2m (ok)
> > > >     v5 posted
> > > >    -  Ian Campbell
> > > Committed.
> > > 
> > > > == QEMU ==
> > > > 
> > > > *  Rebase of QEMU 2.0 and SeaBIOS (fair)
> > > >    -  Ian Jackson
> > > What is this? Neither of them sound like Ian J things. Stefano maintains
> > > Qemu and I take care of SeaBIOS.
> > Yeah, it should be me for QEMU and it is done.
> > 
> > 
> > > >From the SeaBIOS side we are currently using the latest upstream.
> > > 
> > > IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
> > > with, but he should confirm...
> > Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> > again a new QEMU upstream release before 4.5.
> 
> qemu 2.1 is near to be released, now is rc3, why not update to 2.1?

I don't think we would have enough time to test it throughly.

Re: Xen 4.5 development update (July update)

[Fabio Fantoni]

Il 23/07/2014 15:45, Stefano Stabellini ha scritto:
> On Wed, 23 Jul 2014, Fabio Fantoni wrote:
>> Il 23/07/2014 12:20, Stefano Stabellini ha scritto:
>>> On Wed, 23 Jul 2014, Ian Campbell wrote:
>>>> (trimming CC to just those related to things I've commented on)
>>>>
>>>> On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
>>>>
>>>>> fair - still working on it, patches are prototypes or RFC
>>>> You've used this (correctly per your definition here) on various things
>>>> which it seems to me are very unlikely to make it for 4.5, i.e. things
>>>> which are really early prototypes etc, which made me pause every time I
>>>> ready it and have to think back to the definition.
>>>>
>>>> I guess what I'm saying is that "fair" is not a good label for this
>>>> state, it implies that while the thing is a WIP it is still likely to
>>>> make it for 4.5.
>>>>
>>>> I think you need a lower ranked WIP label for things which are in that
>>>> state of prototype/RFC but not likely to make 4.5. "wip" or "inprogress"
>>>> perhaps.
>>>>
>>>>> = Open =
>>>>>
>>>>> == ARM ==
>>>> [...]
>>>>
>>>>> *  ARM VM save/restore/live migration (ok)
>>>>>     -  Junghyun Yoo
>>>> I've not heard from Junghyun since the initial reposting, not sure what
>>>> the prognosis is but given lack of support for SMP and some of the other
>>>> issues I'm more incline to suggest fair rather than OK. Jinghyun, do you
>>>> have any thoughts?
>>>>
>>>> It's possible that the "save/restore/dead-migration" bit is "ok", it's
>>>> the live migration bits where the issues mostly remain iffy.
>>>>
>>>> Also this is dependent on the migration v2 by Andrew et al.
>>>>
>>>>> *  ARM: Use super pages in p2m (ok)
>>>>>      v5 posted
>>>>>     -  Ian Campbell
>>>> Committed.
>>>>
>>>>> == QEMU ==
>>>>>
>>>>> *  Rebase of QEMU 2.0 and SeaBIOS (fair)
>>>>>     -  Ian Jackson
>>>> What is this? Neither of them sound like Ian J things. Stefano maintains
>>>> Qemu and I take care of SeaBIOS.
>>> Yeah, it should be me for QEMU and it is done.
>>>
>>>
>>>> >From the SeaBIOS side we are currently using the latest upstream.
>>>>
>>>> IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
>>>> with, but he should confirm...
>>> Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
>>> again a new QEMU upstream release before 4.5.
>> qemu 2.1 is near to be released, now is rc3, why not update to 2.1?
> I don't think we would have enough time to test it throughly.
However, the major distributions will update to latest qemu tested or 
notin Xen.
I think it's always best to use the latest stable qemu in xen-unstable, 
at least until will xen reach the freeze.

Re: Xen 4.5 development update (July update)

[Konrad Rzeszutek Wilk]

On Tue, Jul 22, 2014 at 08:47:13PM -0400, Boris Ostrovsky wrote:
> On 07/22/2014 08:28 PM, konrad.wilk@oracle.com wrote:
> >
> >*  IO-NUMA - hwloc and xl (fair)
> >    Andrew Cooper had an RFC patch for hwloc
> >   -  Boris Ostrovsky
> 
> 
> I don't think we ever planned this for 4.5. This is a "none".

Right. I had it in Xen 4.6 deferred line. Will fix it to 'none'
> 
> -boris
> 
> 

Re: Xen 4.5 development update (July update)

[Konrad Rzeszutek Wilk]

On Wed, Jul 23, 2014 at 10:51:46AM +0100, Ian Campbell wrote:
> (trimming CC to just those related to things I've commented on)
> 
> On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
> 
> > fair - still working on it, patches are prototypes or RFC
> 
> You've used this (correctly per your definition here) on various things
> which it seems to me are very unlikely to make it for 4.5, i.e. things
> which are really early prototypes etc, which made me pause every time I
> ready it and have to think back to the definition.
> 
> I guess what I'm saying is that "fair" is not a good label for this
> state, it implies that while the thing is a WIP it is still likely to
> make it for 4.5.
> 
> I think you need a lower ranked WIP label for things which are in that
> state of prototype/RFC but not likely to make 4.5. "wip" or "inprogress"
> perhaps.

Or I can start weeding them out and push them in the Xen 4.6 territory.
I was thinking that in August I would do that.
> 
> > = Open =
> > 
> > == ARM == 
> [...]
> 
> > *  ARM VM save/restore/live migration (ok)
> >   -  Junghyun Yoo
> 
> I've not heard from Junghyun since the initial reposting, not sure what
> the prognosis is but given lack of support for SMP and some of the other
> issues I'm more incline to suggest fair rather than OK. Jinghyun, do you
> have any thoughts?
> 
> It's possible that the "save/restore/dead-migration" bit is "ok", it's
> the live migration bits where the issues mostly remain iffy.

OK, downgraded it.
> 
> Also this is dependent on the migration v2 by Andrew et al.

That would certainly make it 'fair' or 'none' as said code dependent
on Andrew, et al. code has not been posted.
> 
> > *  ARM: Use super pages in p2m (ok)
> >    v5 posted
> >   -  Ian Campbell
> 
> Committed.

Excellent!
> 
> > == QEMU == 
> > 
> > *  Rebase of QEMU 2.0 and SeaBIOS (fair)
> >   -  Ian Jackson
> 
> What is this? Neither of them sound like Ian J things. Stefano maintains
> Qemu and I take care of SeaBIOS.

Right.
> 
> >From the SeaBIOS side we are currently using the latest upstream.

Is there a specific tag we want to use? 
> 
> IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
> with, but he should confirm...
> 
> Ian.
> 

Re: Xen 4.5 development update (July update)

[Ian Campbell]

On Wed, 2014-07-23 at 12:18 -0400, Konrad Rzeszutek Wilk wrote:

> > >From the SeaBIOS side we are currently using the latest upstream.
> 
> Is there a specific tag we want to use? 

We are using rel-1.7.5 which is the current latest.

If when 1.7.6 or 1.7.5.1 occurs I'll evaluate that based on where we are
in the release process.

Ian.

Re: Xen 4.5 development update (July update)

[Konrad Rzeszutek Wilk]

> > >From the SeaBIOS side we are currently using the latest upstream.
> > 
> > IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
> > with, but he should confirm...
> 
> Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> again a new QEMU upstream release before 4.5.

Is there an ETA when you want to push it out? So far I see that
 qemu-upstream-unstable master has not been updated.

Re: Xen 4.5 development update (July update)

[Don Slutz]

On 07/23/14 09:03, Stefano Stabellini wrote:
> On Wed, 23 Jul 2014, Don Slutz wrote:
>> On 07/23/14 06:20, Stefano Stabellini wrote:
>>> On Wed, 23 Jul 2014, Ian Campbell wrote:
>>>> (trimming CC to just those related to things I've commented on)
>>>>
>>>> On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
>>>>
>>>>> == QEMU ==
>>>>>
>>>>> *  Rebase of QEMU 2.0 and SeaBIOS (fair)
>>>>>     -  Ian Jackson
>>>> What is this? Neither of them sound like Ian J things. Stefano maintains
>>>> Qemu and I take care of SeaBIOS.
>>> Yeah, it should be me for QEMU and it is done.
>>>
>>>
>>>> >From the SeaBIOS side we are currently using the latest upstream.
>>>>
>>>> IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
>>>> with, but he should confirm...
>>> Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
>>> again a new QEMU upstream release before 4.5.
>>>
>> Based on this,
>>
>> Message-ID: <1405424067-23136-1-git-send-email-dslutz@verizon.com>
>> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01923.html
>>
>> Needs to wait for 4.6
>>      -Don Slutz
> I would be happy to backport that patch once it is upstream.

The change that was accepted by QEMU upstream depends on a big batch
of other changes (commit c4f5cdc53f181f6fe84a0f1bf99914598934a8a6)
So the backport to QEMU 2.0.x is not simple.

I can provide a QEMU 2.0.x patch that is based on the accepted name and
way it is used, but uses a global variable instead of a property on the
machine object.  I.E. a simple patch.

Let me know if you want this.
     -Don Slutz

Re: Xen 4.5 development update (July update)

[Stefano Stabellini]

On Wed, 23 Jul 2014, Don Slutz wrote:
> On 07/23/14 09:03, Stefano Stabellini wrote:
> > On Wed, 23 Jul 2014, Don Slutz wrote:
> > > On 07/23/14 06:20, Stefano Stabellini wrote:
> > > > On Wed, 23 Jul 2014, Ian Campbell wrote:
> > > > > (trimming CC to just those related to things I've commented on)
> > > > > 
> > > > > On Tue, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
> > > > > 
> > > > > > == QEMU ==
> > > > > > 
> > > > > > *  Rebase of QEMU 2.0 and SeaBIOS (fair)
> > > > > >     -  Ian Jackson
> > > > > What is this? Neither of them sound like Ian J things. Stefano
> > > > > maintains
> > > > > Qemu and I take care of SeaBIOS.
> > > > Yeah, it should be me for QEMU and it is done.
> > > > 
> > > > 
> > > > > >From the SeaBIOS side we are currently using the latest upstream.
> > > > > 
> > > > > IIRC Stefano has merged the version of qemu which he intends 4.5 to
> > > > > ship
> > > > > with, but he should confirm...
> > > > Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> > > > again a new QEMU upstream release before 4.5.
> > > > 
> > > Based on this,
> > > 
> > > Message-ID: <1405424067-23136-1-git-send-email-dslutz@verizon.com>
> > > http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01923.html
> > > 
> > > Needs to wait for 4.6
> > >      -Don Slutz
> > I would be happy to backport that patch once it is upstream.
> 
> The change that was accepted by QEMU upstream depends on a big batch
> of other changes (commit c4f5cdc53f181f6fe84a0f1bf99914598934a8a6)
> So the backport to QEMU 2.0.x is not simple.
> 
> I can provide a QEMU 2.0.x patch that is based on the accepted name and
> way it is used, but uses a global variable instead of a property on the
> machine object.  I.E. a simple patch.

Yes, please. Thank you.

- Stefano

Re: Xen 4.5 development update (July update)

[Stefano Stabellini]

On Wed, 23 Jul 2014, Konrad Rzeszutek Wilk wrote:
> > > >From the SeaBIOS side we are currently using the latest upstream.
> > > 
> > > IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
> > > with, but he should confirm...
> > 
> > Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> > again a new QEMU upstream release before 4.5.
> 
> Is there an ETA when you want to push it out? So far I see that
>  qemu-upstream-unstable master has not been updated.

It has. The tip is:

commit 779640a3f4f58633e8575a534838ec79b4982107
Author: Luiz Capitulino <lcapitulino@redhat.com>
Date:   Thu Jun 19 10:13:43 2014 -0400

    fpu: softfloat: drop INLINE macro

and it is based on v2.0.0.

Re: Xen 4.5 development update (July update)

[Konrad Rzeszutek Wilk]

On Thu, Jul 24, 2014 at 12:23:17PM +0100, Stefano Stabellini wrote:
> On Wed, 23 Jul 2014, Konrad Rzeszutek Wilk wrote:
> > > > >From the SeaBIOS side we are currently using the latest upstream.
> > > > 
> > > > IIRC Stefano has merged the version of qemu which he intends 4.5 to ship
> > > > with, but he should confirm...
> > > 
> > > Yes, I have already merged QEMU 2.0.0 and I am not planning to merge
> > > again a new QEMU upstream release before 4.5.
> > 
> > Is there an ETA when you want to push it out? So far I see that
> >  qemu-upstream-unstable master has not been updated.
> 
> It has. The tip is:
> 
> commit 779640a3f4f58633e8575a534838ec79b4982107
> Author: Luiz Capitulino <lcapitulino@redhat.com>
> Date:   Thu Jun 19 10:13:43 2014 -0400
> 
>     fpu: softfloat: drop INLINE macro
> 
> and it is based on v2.0.0.

<scratches his head>

Looking at git://git.qemu.org/qemu.git I see:
a9e8aeb Update version for v2.0.0 release

oh, which I see now in the master, way way back in the log. And then
you backported a bunch of stuff from v2.1.0 in the tree.

Right, that makes more sense now.

Thank you!

[PATCH 0/2] Back port Add new machine opt max-ram-below-4g

[Don Slutz]

I also back ported:

commit 3c2a96699e9fc09b5712dacfe200cdaaff0bb55c
xen-hvm: Fix xen_hvm_init() to adjust pc memory layout

As patch #1, because it is a bug fix and it is untangled with patch
#2.  This way the change to xen-hvm.c is closer to QEMU 2.1.0's
version.

This back port (#2) uses the global max_ram_below_4g instead of the
newly added pc_machine object.

Don Slutz (2):
  xen-hvm: Fix xen_hvm_init() to adjust pc memory layout
  Backport pc & q35: Add new machine opt max-ram-below-4g

 hw/i386/pc_piix.c    | 55 +++++++++++++++++++++++++++++++++++++---------------
 hw/i386/pc_q35.c     | 53 ++++++++++++++++++++++++++++++++++++--------------
 include/hw/xen/xen.h |  3 ++-
 vl.c                 | 28 ++++++++++++++++++++++++++
 xen-hvm-stub.c       |  3 ++-
 xen-hvm.c            | 53 ++++++++++++++++++++++++++++++++------------------
 6 files changed, 143 insertions(+), 52 deletions(-)

-- 
1.8.4

[PATCH 1/2] xen-hvm: Fix xen_hvm_init() to adjust pc memory layout

[Don Slutz]

This is just below_4g_mem_size and above_4g_mem_size which is used later in QEMU.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 3c2a96699e9fc09b5712dacfe200cdaaff0bb55c)
---
 hw/i386/pc_piix.c    | 31 ++++++++++++++++---------------
 hw/i386/pc_q35.c     | 29 +++++++++++++++--------------
 include/hw/xen/xen.h |  3 ++-
 xen-hvm-stub.c       |  3 ++-
 xen-hvm.c            | 24 ++++++++++++++----------
 5 files changed, 49 insertions(+), 41 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7930a26..bd52f6e 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -96,21 +96,6 @@ static void pc_init1(QEMUMachineInitArgs *args,
     FWCfgState *fw_cfg = NULL;
     PcGuestInfo *guest_info;
 
-    if (xen_enabled() && xen_hvm_init(&ram_memory) != 0) {
-        fprintf(stderr, "xen hardware virtual machine initialisation failed\n");
-        exit(1);
-    }
-
-    icc_bridge = qdev_create(NULL, TYPE_ICC_BRIDGE);
-    object_property_add_child(qdev_get_machine(), "icc-bridge",
-                              OBJECT(icc_bridge), NULL);
-
-    pc_cpus_init(args->cpu_model, icc_bridge);
-
-    if (kvm_enabled() && kvmclock_enabled) {
-        kvmclock_create();
-    }
-
     /* Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory).
      * If it doesn't, we need to split it in chunks below and above 4G.
      * In any case, try to make sure that guest addresses aligned at
@@ -127,6 +112,22 @@ static void pc_init1(QEMUMachineInitArgs *args,
         below_4g_mem_size = args->ram_size;
     }
 
+    if (xen_enabled() && xen_hvm_init(&below_4g_mem_size, &above_4g_mem_size,
+                                      &ram_memory) != 0) {
+        fprintf(stderr, "xen hardware virtual machine initialisation failed\n");
+        exit(1);
+    }
+
+    icc_bridge = qdev_create(NULL, TYPE_ICC_BRIDGE);
+    object_property_add_child(qdev_get_machine(), "icc-bridge",
+                              OBJECT(icc_bridge), NULL);
+
+    pc_cpus_init(args->cpu_model, icc_bridge);
+
+    if (kvm_enabled() && kvmclock_enabled) {
+        kvmclock_create();
+    }
+
     if (pci_enabled) {
         pci_memory = g_new(MemoryRegion, 1);
         memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c844dc2..6e34fe1 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -83,20 +83,6 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
     DeviceState *icc_bridge;
     PcGuestInfo *guest_info;
 
-    if (xen_enabled() && xen_hvm_init(&ram_memory) != 0) {
-        fprintf(stderr, "xen hardware virtual machine initialisation failed\n");
-        exit(1);
-    }
-
-    icc_bridge = qdev_create(NULL, TYPE_ICC_BRIDGE);
-    object_property_add_child(qdev_get_machine(), "icc-bridge",
-                              OBJECT(icc_bridge), NULL);
-
-    pc_cpus_init(args->cpu_model, icc_bridge);
-    pc_acpi_init("q35-acpi-dsdt.aml");
-
-    kvmclock_create();
-
     /* Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory
      * and 256 Mbytes for PCI Express Enhanced Configuration Access Mapping
      * also known as MMCFG).
@@ -115,6 +101,21 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
         below_4g_mem_size = args->ram_size;
     }
 
+    if (xen_enabled() && xen_hvm_init(&below_4g_mem_size, &above_4g_mem_size,
+                                      &ram_memory) != 0) {
+        fprintf(stderr, "xen hardware virtual machine initialisation failed\n");
+        exit(1);
+    }
+
+    icc_bridge = qdev_create(NULL, TYPE_ICC_BRIDGE);
+    object_property_add_child(qdev_get_machine(), "icc-bridge",
+                              OBJECT(icc_bridge), NULL);
+
+    pc_cpus_init(args->cpu_model, icc_bridge);
+    pc_acpi_init("q35-acpi-dsdt.aml");
+
+    kvmclock_create();
+
     /* pci enabled */
     if (pci_enabled) {
         pci_memory = g_new(MemoryRegion, 1);
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 9d549fc..0f3942e 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -37,10 +37,11 @@ void xen_cmos_set_s3_resume(void *opaque, int irq, int level);
 qemu_irq *xen_interrupt_controller_init(void);
 
 int xen_init(QEMUMachine *machine);
-int xen_hvm_init(MemoryRegion **ram_memory);
 void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
+int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
+                 MemoryRegion **ram_memory);
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
                    struct MemoryRegion *mr);
 void xen_modified_memory(ram_addr_t start, ram_addr_t length);
diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
index 4eb27b5..2d98696 100644
--- a/xen-hvm-stub.c
+++ b/xen-hvm-stub.c
@@ -51,7 +51,8 @@ void xen_modified_memory(ram_addr_t start, ram_addr_t length)
 {
 }
 
-int xen_hvm_init(MemoryRegion **ram_memory)
+int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
+                 MemoryRegion **ram_memory)
 {
     return 0;
 }
diff --git a/xen-hvm.c b/xen-hvm.c
index 8c69b34..ad9ee45 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -155,10 +155,11 @@ qemu_irq *xen_interrupt_controller_init(void)
 
 /* Memory Ops */
 
-static void xen_ram_init(ram_addr_t ram_size, MemoryRegion **ram_memory_p)
+static void xen_ram_init(ram_addr_t *below_4g_mem_size,
+                         ram_addr_t *above_4g_mem_size,
+                         ram_addr_t ram_size, MemoryRegion **ram_memory_p)
 {
     MemoryRegion *sysmem = get_system_memory();
-    ram_addr_t below_4g_mem_size, above_4g_mem_size = 0;
     ram_addr_t block_len;
 
     block_len = ram_size;
@@ -173,10 +174,11 @@ static void xen_ram_init(ram_addr_t ram_size, MemoryRegion **ram_memory_p)
     vmstate_register_ram_global(&ram_memory);
 
     if (ram_size >= HVM_BELOW_4G_RAM_END) {
-        above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
-        below_4g_mem_size = HVM_BELOW_4G_RAM_END;
+        *above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
+        *below_4g_mem_size = HVM_BELOW_4G_RAM_END;
     } else {
-        below_4g_mem_size = ram_size;
+        *above_4g_mem_size = 0;
+        *below_4g_mem_size = ram_size;
     }
 
     memory_region_init_alias(&ram_640k, NULL, "xen.ram.640k",
@@ -189,12 +191,13 @@ static void xen_ram_init(ram_addr_t ram_size, MemoryRegion **ram_memory_p)
      * the Options ROM, so it is registered here as RAM.
      */
     memory_region_init_alias(&ram_lo, NULL, "xen.ram.lo",
-                             &ram_memory, 0xc0000, below_4g_mem_size - 0xc0000);
+                             &ram_memory, 0xc0000,
+                             *below_4g_mem_size - 0xc0000);
     memory_region_add_subregion(sysmem, 0xc0000, &ram_lo);
-    if (above_4g_mem_size > 0) {
+    if (*above_4g_mem_size > 0) {
         memory_region_init_alias(&ram_hi, NULL, "xen.ram.hi",
                                  &ram_memory, 0x100000000ULL,
-                                 above_4g_mem_size);
+                                 *above_4g_mem_size);
         memory_region_add_subregion(sysmem, 0x100000000ULL, &ram_hi);
     }
 }
@@ -958,7 +961,8 @@ static void xen_wakeup_notifier(Notifier *notifier, void *data)
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0);
 }
 
-int xen_hvm_init(MemoryRegion **ram_memory)
+int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
+                 MemoryRegion **ram_memory)
 {
     int i, rc;
     unsigned long ioreq_pfn;
@@ -1036,7 +1040,7 @@ int xen_hvm_init(MemoryRegion **ram_memory)
 
     /* Init RAM management */
     xen_map_cache_init(xen_phys_offset_to_gaddr, state);
-    xen_ram_init(ram_size, ram_memory);
+    xen_ram_init(below_4g_mem_size, above_4g_mem_size, ram_size, ram_memory);
 
     qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
 
-- 
1.8.4

[PATCH 2/2] Backport pc & q35: Add new machine opt max-ram-below-4g

[Don Slutz]

This is a xen only backport of 2 QEMU 2.1.0 changes:

commit c87b1520726f7ae1e698a41f07043d1b539ac88c
  pc & q35: Add new machine opt max-ram-below-4g
commit c4f5cdc53f181f6fe84a0f1bf99914598934a8a6
  xen-hvm: Handle machine opt max-ram-below-4g

It changes all machine types to have this, not just pc & q35.  But
only pc & q35 machines do anything with it.  I.E. this machine
option will be ignored by other types.

If you add enough PCI devices then all mmio for them will not fit
below 4G which may not be the layout the user wanted. This allows
you to increase the below 4G address space that PCI devices can use
(aka decrease ram below 4G) and therefore in more cases not have any
mmio that is above 4G.

For example using "-machine pc,max-ram-below-4g=2G" on the command
line will limit the amount of ram that is below 4G to 2G.

Note: this machine option cannot be used to increase the amount of
ram below 4G.

Signed-off-by: Don Slutz <dslutz@verizon.com>
---
 hw/i386/pc_piix.c | 24 +++++++++++++++++++++++-
 hw/i386/pc_q35.c  | 24 +++++++++++++++++++++++-
 vl.c              | 28 ++++++++++++++++++++++++++++
 xen-hvm.c         | 35 +++++++++++++++++++++++------------
 4 files changed, 97 insertions(+), 14 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index bd52f6e..d506630 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -48,10 +48,13 @@
 #include "exec/address-spaces.h"
 #include "hw/acpi/acpi.h"
 #include "cpu.h"
+#include "qemu/error-report.h"
 #ifdef CONFIG_XEN
 #  include <xen/hvm/hvm_info_table.h>
 #endif
 
+extern uint64_t max_ram_below_4g;
+
 #define MAX_IDE_BUS 2
 
 static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
@@ -95,6 +98,7 @@ static void pc_init1(QEMUMachineInitArgs *args,
     DeviceState *icc_bridge;
     FWCfgState *fw_cfg = NULL;
     PcGuestInfo *guest_info;
+    ram_addr_t lowmem;
 
     /* Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory).
      * If it doesn't, we need to split it in chunks below and above 4G.
@@ -104,7 +108,25 @@ static void pc_init1(QEMUMachineInitArgs *args,
      * breaking migration.
      */
     if (args->ram_size >= 0xe0000000) {
-        ram_addr_t lowmem = gigabyte_align ? 0xc0000000 : 0xe0000000;
+        lowmem = gigabyte_align ? 0xc0000000 : 0xe0000000;
+    } else {
+        lowmem = 0xe0000000;
+    }
+
+    /* Handle the machine opt max-ram-below-4g.  It is basicly doing
+     * min(qemu limit, user limit).
+     */
+    if (lowmem > max_ram_below_4g) {
+        lowmem = max_ram_below_4g;
+        if (args->ram_size - lowmem > lowmem &&
+            lowmem & ((1ULL << 30) - 1)) {
+            error_report("Warning: Large machine and max_ram_below_4g(%"PRIu64
+                         ") not a multiple of 1G; possible bad performance.",
+                         max_ram_below_4g);
+        }
+    }
+
+    if (args->ram_size >= lowmem) {
         above_4g_mem_size = args->ram_size - lowmem;
         below_4g_mem_size = lowmem;
     } else {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 6e34fe1..c529e02 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -44,6 +44,9 @@
 #include "hw/ide/ahci.h"
 #include "hw/usb.h"
 #include "hw/cpu/icc_bus.h"
+#include "qemu/error-report.h"
+
+extern uint64_t max_ram_below_4g;
 
 /* ICH9 AHCI has 6 ports */
 #define MAX_SATA_PORTS     6
@@ -82,6 +85,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
     PCIDevice *ahci;
     DeviceState *icc_bridge;
     PcGuestInfo *guest_info;
+    ram_addr_t lowmem;
 
     /* Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory
      * and 256 Mbytes for PCI Express Enhanced Configuration Access Mapping
@@ -93,7 +97,25 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
      * breaking migration.
      */
     if (args->ram_size >= 0xb0000000) {
-        ram_addr_t lowmem = gigabyte_align ? 0x80000000 : 0xb0000000;
+        lowmem = gigabyte_align ? 0x80000000 : 0xb0000000;
+    } else {
+        lowmem = 0xb0000000;
+    }
+
+    /* Handle the machine opt max-ram-below-4g.  It is basicly doing
+     * min(qemu limit, user limit).
+     */
+    if (lowmem > max_ram_below_4g) {
+        lowmem = max_ram_below_4g;
+        if (args->ram_size - lowmem > lowmem &&
+            lowmem & ((1ULL << 30) - 1)) {
+            error_report("Warning: Large machine and max_ram_below_4g(%"PRIu64
+                         ") not a multiple of 1G; possible bad performance.",
+                         max_ram_below_4g);
+        }
+    }
+
+    if (args->ram_size >= lowmem) {
         above_4g_mem_size = args->ram_size - lowmem;
         below_4g_mem_size = lowmem;
     } else {
diff --git a/vl.c b/vl.c
index 9975e5a..83927c9 100644
--- a/vl.c
+++ b/vl.c
@@ -212,6 +212,7 @@ static NotifierList machine_init_done_notifiers =
 
 static bool tcg_allowed = true;
 bool xen_allowed;
+uint64_t max_ram_below_4g = 1ULL << 32; /* 4G */
 uint32_t xen_domid;
 enum xen_mode xen_mode = XEN_EMULATE;
 static int tcg_tb_size;
@@ -382,6 +383,10 @@ static QemuOptsList qemu_machine_opts = {
             .name = "kvm-type",
             .type = QEMU_OPT_STRING,
             .help = "Specifies the KVM virtualization mode (HV, PR)",
+        },{
+            .name = "max-ram-below-4g",
+            .type = QEMU_OPT_SIZE,
+            .help = "maximum ram below the 4G boundary (32bit boundary)",
         },
         { /* End of list */ }
     },
@@ -4182,6 +4187,29 @@ int main(int argc, char **argv, char **envp)
     kernel_cmdline = qemu_opt_get(machine_opts, "append");
     bios_name = qemu_opt_get(machine_opts, "firmware");
 
+    max_ram_below_4g = qemu_opt_get_size(machine_opts,
+                                         "max-ram-below-4g",
+                                         max_ram_below_4g);
+
+    if (max_ram_below_4g > (1ULL << 32)) {
+        Error *local_err = NULL;
+        error_set(&local_err, ERROR_CLASS_GENERIC_ERROR,
+                  "Machine option 'max-ram-below-4g=%"PRIu64
+                  "' expects size less than or equal to 4G",
+                  max_ram_below_4g);
+        if (local_err) {
+            error_report("%s", error_get_pretty(local_err));
+            error_free(local_err);
+            exit(1);
+        }
+    }
+
+    if (max_ram_below_4g < (1ULL << 20)) {
+        error_report("Warning: small max_ram_below_4g(%"PRIu64
+                     ") less than 1M.  BIOS may not work..",
+                     max_ram_below_4g);
+    }
+
     boot_order = machine->default_boot_order;
     opts = qemu_opts_find(qemu_find_opts("boot-opts"), NULL);
     if (opts) {
diff --git a/xen-hvm.c b/xen-hvm.c
index ad9ee45..a573a20 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -26,6 +26,8 @@
 #include <xen/hvm/params.h>
 #include <xen/hvm/e820.h>
 
+extern uint64_t max_ram_below_4g;
+
 //#define DEBUG_XEN_HVM
 
 #ifdef DEBUG_XEN_HVM
@@ -161,25 +163,34 @@ static void xen_ram_init(ram_addr_t *below_4g_mem_size,
 {
     MemoryRegion *sysmem = get_system_memory();
     ram_addr_t block_len;
+    uint64_t user_lowmem = max_ram_below_4g;
 
-    block_len = ram_size;
-    if (ram_size >= HVM_BELOW_4G_RAM_END) {
-        /* Xen does not allocate the memory continuously, and keep a hole at
-         * HVM_BELOW_4G_MMIO_START of HVM_BELOW_4G_MMIO_LENGTH
-         */
-        block_len += HVM_BELOW_4G_MMIO_LENGTH;
+    /* Handle the machine opt max-ram-below-4g.  It is basically doing
+     * min(xen limit, user limit).
+     */
+    if (HVM_BELOW_4G_RAM_END <= user_lowmem) {
+        user_lowmem = HVM_BELOW_4G_RAM_END;
     }
-    memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len);
-    *ram_memory_p = &ram_memory;
-    vmstate_register_ram_global(&ram_memory);
 
-    if (ram_size >= HVM_BELOW_4G_RAM_END) {
-        *above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
-        *below_4g_mem_size = HVM_BELOW_4G_RAM_END;
+    if (ram_size >= user_lowmem) {
+        *above_4g_mem_size = ram_size - user_lowmem;
+        *below_4g_mem_size = user_lowmem;
     } else {
         *above_4g_mem_size = 0;
         *below_4g_mem_size = ram_size;
     }
+    if (!*above_4g_mem_size) {
+        block_len = ram_size;
+    } else {
+        /*
+         * Xen does not allocate the memory continuously, it keeps a
+         * hole of the size computed above or passed in.
+         */
+        block_len = (1ULL << 32) + *above_4g_mem_size;
+    }
+    memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len);
+    *ram_memory_p = &ram_memory;
+    vmstate_register_ram_global(&ram_memory);
 
     memory_region_init_alias(&ram_640k, NULL, "xen.ram.640k",
                              &ram_memory, 0, 0xa0000);
-- 
1.8.4

Re: [PATCH 0/2] Back port Add new machine opt max-ram-below-4g

[Stefano Stabellini]

On Mon, 28 Jul 2014, Don Slutz wrote:
> I also back ported:
> 
> commit 3c2a96699e9fc09b5712dacfe200cdaaff0bb55c
> xen-hvm: Fix xen_hvm_init() to adjust pc memory layout
> 
> As patch #1, because it is a bug fix and it is untangled with patch
> #2.  This way the change to xen-hvm.c is closer to QEMU 2.1.0's
> version.
> 
> This back port (#2) uses the global max_ram_below_4g instead of the
> newly added pc_machine object.

done


> Don Slutz (2):
>   xen-hvm: Fix xen_hvm_init() to adjust pc memory layout
>   Backport pc & q35: Add new machine opt max-ram-below-4g
> 
>  hw/i386/pc_piix.c    | 55 +++++++++++++++++++++++++++++++++++++---------------
>  hw/i386/pc_q35.c     | 53 ++++++++++++++++++++++++++++++++++++--------------
>  include/hw/xen/xen.h |  3 ++-
>  vl.c                 | 28 ++++++++++++++++++++++++++
>  xen-hvm-stub.c       |  3 ++-
>  xen-hvm.c            | 53 ++++++++++++++++++++++++++++++++------------------
>  6 files changed, 143 insertions(+), 52 deletions(-)
> 
> -- 
> 1.8.4
> 

Re: Xen 4.5 development update (July update)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 813 bytes --]

On mar, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:

> == x86 == 

> *  HT enabled, virtualization overhead is high (Xen 4.4) (none)
>    kernbench demonstrated it
>    looking and tracing it
>   -  Dario Faggioli
> 
There is a (sub-)thread sill ongoing here:
http://www.gossamer-threads.com/lists/xen/devel/339409

However, there have been found counterexamples, i.e., numbers showing
that virt overhead is similar with and without HT, so I think this
bullet can go away (not sure with what tracking status...)

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Xen 4.5 development update (July update)

[Meng Xu]

[-- Attachment #1.1: Type: text/plain, Size: 842 bytes --]

 Hi Konrad,


> *  XenRT (Preemptive Global Earliest Deadline First) (fair)
>    RFC patch posted (v1)
>   -  Meng Xu
>
>
I'm going to release the version 2 of this XenRT patches soon. I hope to
settle down the xen tool for the XenRT patch in the version 2.

The current status is: The scheduler can work well and we had small tests
on this scheduler.  (Any suggestion on automatic testing the scheduler for
production?) I will include the progress details in the email of the
version 2.

The main functionality of this scheduler is almost done. (Well, we only
need to add the TRACE in the next version to finish all of the
functionality.) The current work focuses on improving the scheduler's
performance and scalability.

Thanks,

Meng



-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

[-- Attachment #1.2: Type: text/html, Size: 1205 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.5 development update (July update)

[Konrad Rzeszutek Wilk]

On Mon, Jul 28, 2014 at 07:35:22PM +0200, Dario Faggioli wrote:
> On mar, 2014-07-22 at 20:28 -0400, konrad.wilk@oracle.com wrote:
> 
> > == x86 == 
> 
> > *  HT enabled, virtualization overhead is high (Xen 4.4) (none)
> >    kernbench demonstrated it
> >    looking and tracing it
> >   -  Dario Faggioli
> > 
> There is a (sub-)thread sill ongoing here:
> http://www.gossamer-threads.com/lists/xen/devel/339409
> 
> However, there have been found counterexamples, i.e., numbers showing
> that virt overhead is similar with and without HT, so I think this
> bullet can go away (not sure with what tracking status...)

The 'This confirms, for me, that it's an SMT balancing issue that we're seen. '
is not an issue anymore? As in we can get bad and good results depending
on the workload?

Now here is another question - did you run the guests with 'xen_nopvspin'
to see if this was an PV ticketlock (or the lack of it) issue?

Also what did the " I'll try more runs, e.g. with number of VCPUs equal
less than nr_corse/2 and see what happens." come out to be?

Thank you!
> 
> Dario
> 
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>