This information will be mirrored on the Xen 4.4 Roadmap wiki page:
http://wiki.xen.org/wiki/Xen_Roadmap/4.4
Rather than try to predict precisely what will make it into what
release (which was something of a disaster last release), I''m just
going to borrow a term from the Agile world and call all uncompleted
features the "Backlog". I''ll still track who is doing what,
and when
we get close, what state things seem to be in.
As mentioned in another e-mail, we''ll also be working on improving the
regression tester. Feel free to join us.
And as always, if you are working on a feature / bug that you want
tracked, please respond to this e-mail.
= Timeline
As discussed elsewhere, I am proposing a 6-month release cycle. Xen
4.3 was released on 9 July. That would give us a release on 9 January
2014. This is fairly close after the Christmas season, so I propose
to make the estimated release date later, on 21 January, giving a few
extra weeks for the holiday season:
* Feature freeze: 18 October 2013
* Code freezing point: 8 November 2013
* First RC: 26 November 2013
* Release: 21 January 2014
Feedback on the estimated dates is welcome.
Last updated: 8 August 2013
== Completed =
[none]
== Open =
* xend still in tree
* qemu-upstream not freeing pirq
> http://www.gossamer-threads.com/lists/xen/devel/281498
status: patches posted
* __update_vcpu_system_time if system_time comes out negative
* xl pci-detach broken for pv guests?
> http://bugs.xenproject.org/xen/bug/12
> kernel doesn''t know about moving into states 7 and 8
status: External
* Race in PV shutdown between tool detection and shutdown watch
> http://www.gossamer-threads.com/lists/xen/devel/282467
> Nothing to do with ACPI
status: Probably a bug in Linux xen drivers
== Backlog =
=== Testing coverage ==
* Network driver domains
@George
* new libxl w/ previous versions of xl
@IanJ
* Host S3 suspend
@bguthro
* Default [example] XSM policy
@Stefano to ask Daniel D
* Xen on ARM
# hardware
@ianc
emulator: @stefano to think about it
* Storage driver domains
@roger
* HVM pci passthrough
@anthony
* Nested virt?
@intel (chased by George)
* Fix SRIOV test (chase intel)
@ianj
* Fix bisector to e-mail blame-worthy parties
@ianj
* Fix xl shutdown
@ianj
* stub domains
@athony
=== Big ticket items ==
* NUMA Memory migration
owner: dario@citrix
status: in progress
* Event channel scalability
owner: david@citrix
status: RFC v5 submitted
Increase limit on event channels (currently 1024 for 32-bit guests,
4096 for 64-bit guests)
* PVH mode (w/ Linux)
owner: mukesh@oracle
status (Linux): 3rd draft patches posted.
status (Xen): v10 posted
* ARM stuff: ??
* Meta: PVIO NUMA improvements
- NUMA affinity for vcpus
owner: Dario
- PV guest NUMA interface
owner: Elena
- Sensible dom0 NUMA layout
- Toolstack pinning backend thread / virq to appropraite d0 vcpu
* qemu-upstream stubdom, Linux
owner: anthony@citrix
status: in progress
qemu-upstream needs a more fully-featured libc than exists in
mini-os. Either work on a minimalist linux-based stubdom with
glibc, or port one of the BSD libcs to minios.
* qemu-upstream stubdom, BSD libc
owner: ianj@citrix
* Network performance improvements
owner: wei@citrix
* Disk performance improvements
* Xen EFI feature: Xen can boot from grub.efi
owner: Daniel Kiper
status: Just begun
prognosis: Fair
* libvirt/libxl integration (external)
> need a status update
- owner: jfehlig@suse, dario@citrix
* Default to credit2
- cpu pinning
- NUMA affinity
- cpu "reservation"
* xenperf
Owner: Boris Otovsky
* blktap3
owner: thanos@citrix
status: on hold pending XenServer decision
* Nested virtualization on Intel
* Nested virtualization on AMD
* Make storage migration possible
owner: ?
status: none
There needs to be a way, either via command-line or via some hooks,
that someone can build a "storage migration" feature on top of libxl
or xl.
* Full-VM snapshotting
owner: ?
status: none
Have a way of coordinating the taking and restoring of VM memory and
disk snapshots. This would involve some investigation into the best
way to accomplish this.
* VM Cloning
owner: ?
status: none
Again, a way of coordinating the memory and disk aspects. Research
into the best way to do this would probably go along with the
snapshotting feature.
* xl vm-{export,import}
owner: ?
status: none
Allow xl to import and export VMs to other formats; particularly
ovf, perhaps the XenServer format, or more.
* Memory: Replace PoD with paging mechanism
owner: george@citrix
status: none
* PV audio (audio for stubdom qemu)
owner: stefano.panella@citrix
status: ?
* Wait queues for mm
> Needed for more advanced paging schemes
owner: ?
status: Draft posted Feb 2012; more work to do.
* V4V: Inter-domain communication
owner (Xen): dominic.curran@citrix.com
status (Xen): patches submitted
owner (Linux driver): stefano.panella@citrix
status (Linux driver): in progress
=== clean-ups ==
* Sort out better memory / ballooning / dom0 autoballooning thing
> Don''t forget NUMA angle
- Inaccurate / incomplete info from HV
* Implement Xen hypervisor dmesg log entry timestamps
* Make network driver domains easier to set up / more useful
- Default backend (submitted)
- Remove unnecessary restriction wrt dom0 hotplug scripts (submitted)
- Make it easy to make a device assignable (in discussion)
- Automatically start/shutdown (xendomains?)
- Pause booting of other domains until network driver domain is up
* libxl: More fine-grained control over when to pass through a device
> Some IOMMUs are secure; some are merely functional, some are not present.
> Allow the adminitrator to set the default
* xl does not handle migrate interruption gracefully
> If you start a localhost migrate, and press "Ctrl-C" in the
middle,
> you get two hung domains
status: Probably not for 4.3
* libxl / xl does not handle failure of remote qemu gracefully
> Easiest way to reproduce:
> - set "vncunused=0" and do a local migrate
> - The "remote" qemu will fail because the vnc port is in use
> The failure isn''t the problem, but everything being stuck
afterwards is
status: Probably not for 4.3
* mac address changes on reboot if not specified in config file
> Needs a robust way to "add" to the config
status: Too much for 4.3
* qxl
>
http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11
- Uninitialized struct element in qemu
- Revert 5479961 to re-enable qxl in xl,libxl
- Option in Xen top-level to enable qxl support in qemu tree
- Fix sse2 MMIO issue
* libxl config file
* libxl: Don''t use RAW format for "URL"-based qdisks (e.g.,
rbd:rbd/foo.img)
- Figure out whether to use a generic URL or have a specific type for each one
- Check existence of disk file for all RAW
* Polish up xenbugtool
owner: wei.liu2@citrix.com
* acpi-related xenstore entries not propagated on migrate
> http://www.gossamer-threads.com/lists/xen/devel/282466
> Only used by hvmloader; only a clean-up, not a bug.
status: Not for 4.3
* Remove hardcoded mobprobe''s in xencommons
owner: Wei Liu
status: still in discussion
* xl USB pass-through for HVM guests using Qemu USB emulation
owner: George
status: v6 patch series posted
* Rationalized backend scripts
owner: roger@citrix
status: patches posted
* Scripts for driver domains (depends on backend scripts)
owner: roger@citrix
status:
* Multi-vector PCI MSI (support at least for Dom0)
owner: jan@suse
status: Patches posted for Intel; AMD not yet done
* xl: passing more defaults in configuration in xl.conf
owner: ?
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.
* xl PVUSB pass-through for PV guests
* xl PVUSB pass-through for HVM guests
owner: George
status: ?
xm/xend supports PVUSB pass-through to guests with PVUSB drivers
(both PV and HVM guests).
- port the xm/xend functionality to xl.
- this PVUSB feature does not require support or emulation from Qemu.
- upstream the Linux frontend/backend drivers. Current
work-in-progress versions are in Konrad''s git tree.
- James Harper''s GPLPV drivers for Windows include PVUSB frontend
drivers.
* Guest EFI booting
- status: tianocore in-tree, some build problems.
Needs new owner.
* Xen EFI feature: pvops dom0 able to make use of EFI run-time
services (external)
owner: Daniel Kiper
status: Just begun
* Serial console improvements
owner: ?
status: Stalled (see below)
-xHCI debug port (Needs hardware)
-Firewire (needs hardware)
On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * blktap3 > owner: thanos@citrix > status: on hold pending XenServer decisionSorry, missed this one -- this is more or less cancelled.
> * qxl > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 > - Uninitialized struct element in qemu > - Revert 5479961 to re-enable qxl in xl,libxl > - Option in Xen top-level to enable qxl support in qemu tree > - Fix sse2 MMIO issueqxl has been re-enabled, but we still haven''t had anyone step up to implement >8-byte IO instructions. Any takers? -George
On 08/08/13 17:14, George Dunlap wrote:>> * qxl >> > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >> - Uninitialized struct element in qemu >> - Revert 5479961 to re-enable qxl in xl,libxl >> - Option in Xen top-level to enable qxl support in qemu tree >> - Fix sse2 MMIO issue > qxl has been re-enabled, but we still haven''t had anyone step up to > implement >8-byte IO instructions. Any takers? > > -GeorgeNot that I have time to look at this, but can this requirement include support for 32 byte IO instructions, to allow for AVX emulation as well as just SSE. ~Andrew> > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Thu, 2013-08-08 at 17:14 +0100, George Dunlap wrote:> > * qxl > > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 > > - Uninitialized struct element in qemu > > - Revert 5479961 to re-enable qxl in xl,libxl > > - Option in Xen top-level to enable qxl support in qemu tree > > - Fix sse2 MMIO issue > > qxl has been re-enabled,Has it? I can''t see a patch with qxl in the title after "libxl: Remove qxl support for the 4.3 release".> but we still haven''t had anyone step up to implement >8-byte IO > instructions. Any takers?Assuming I''m right and it hasn''t been enabled is there any reason this shouldn''t be a prerequisite for enabling qxl? Ian.
On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:> This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I''m just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I''ll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we''ll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome. > > Last updated: 8 August 2013 > > == Completed => > [none] > > == Open => > * xend still in tree > > * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches postedThey did fix the problem Oracle saw and I believe have been Tested-and-Acked.> > * __update_vcpu_system_time if system_time comes out negative > > * xl pci-detach broken for pv guests? > > http://bugs.xenproject.org/xen/bug/12 > > kernel doesn''t know about moving into states 7 and 8 > status: ExternalDidn''t I post a patch for this on Linux - and it is in Linux kernel already.> > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > Nothing to do with ACPI > status: Probably a bug in Linux xen drivers > > == Backlog => > === Testing coverage ==> > * Network driver domains > @George > > * new libxl w/ previous versions of xl > @IanJ > > * Host S3 suspend > @bguthro > > * Default [example] XSM policy > @Stefano to ask Daniel D > > * Xen on ARM > # hardware > @ianc > emulator: @stefano to think about it > > * Storage driver domains > @roger > > * HVM pci passthrough > @anthony > > * Nested virt? > @intel (chased by George) > > * Fix SRIOV test (chase intel) > @ianj > > * Fix bisector to e-mail blame-worthy parties > @ianj > > * Fix xl shutdown > @ianj > > * stub domains > @athony > > === Big ticket items ==> > * NUMA Memory migration > owner: dario@citrix > status: in progress > > * Event channel scalability > owner: david@citrix > status: RFC v5 submitted > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests)aka FIFO thing right?> > * PVH mode (w/ Linux) > owner: mukesh@oracle > status (Linux): 3rd draft patches posted.More like v8. And already Acked - just waiting for ABI to be in some way "nailed down".> status (Xen): v10 posted > > * ARM stuff: ?? > > * Meta: PVIO NUMA improvements > - NUMA affinity for vcpus > owner: Dario > - PV guest NUMA interface > owner: Elena > - Sensible dom0 NUMA layout > - Toolstack pinning backend thread / virq to appropraite d0 vcpu > > * qemu-upstream stubdom, Linux > owner: anthony@citrix > status: in progress > qemu-upstream needs a more fully-featured libc than exists in > mini-os. Either work on a minimalist linux-based stubdom with > glibc, or port one of the BSD libcs to minios. > > * qemu-upstream stubdom, BSD libc > owner: ianj@citrix > > * Network performance improvements > owner: wei@citrix > > * Disk performance improvementsI think you mean blkback and blkfront?> > * Xen EFI feature: Xen can boot from grub.efi > owner: Daniel Kiper > status: Just begun > prognosis: Fair > > * libvirt/libxl integration (external) > > need a status update > - owner: jfehlig@suse, dario@citrix > > * Default to credit2 > - cpu pinning > - NUMA affinity > - cpu "reservation" > > * xenperf > Owner: Boris Otovsky > > * blktap3 > owner: thanos@citrix > status: on hold pending XenServer decision > > * Nested virtualization on Intel > > * Nested virtualization on AMD > > * Make storage migration possible > owner: ? > status: none > There needs to be a way, either via command-line or via some hooks, > that someone can build a "storage migration" feature on top of libxl > or xl. > > * Full-VM snapshotting > owner: ? > status: none > Have a way of coordinating the taking and restoring of VM memory and > disk snapshots. This would involve some investigation into the best > way to accomplish this. > > * VM Cloning > owner: ? > status: none > Again, a way of coordinating the memory and disk aspects. Research > into the best way to do this would probably go along with the > snapshotting feature. > > * xl vm-{export,import} > owner: ? > status: none > Allow xl to import and export VMs to other formats; particularly > ovf, perhaps the XenServer format, or more. > > * Memory: Replace PoD with paging mechanism > owner: george@citrix > status: none > > * PV audio (audio for stubdom qemu) > owner: stefano.panella@citrix > status: ? > > * Wait queues for mm > > Needed for more advanced paging schemes > owner: ? > status: Draft posted Feb 2012; more work to do. > > * V4V: Inter-domain communication > owner (Xen): dominic.curran@citrix.com > status (Xen): patches submitted > owner (Linux driver): stefano.panella@citrix > status (Linux driver): in progress > > === clean-ups ==> > * Sort out better memory / ballooning / dom0 autoballooning thing > > Don''t forget NUMA angle > - Inaccurate / incomplete info from HV > > * Implement Xen hypervisor dmesg log entry timestamps > > * Make network driver domains easier to set up / more useful > - Default backend (submitted) > - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted) > - Make it easy to make a device assignable (in discussion) > - Automatically start/shutdown (xendomains?) > - Pause booting of other domains until network driver domain is up > > * libxl: More fine-grained control over when to pass through a device > > Some IOMMUs are secure; some are merely functional, some are not present. > > Allow the adminitrator to set the default > > * xl does not handle migrate interruption gracefully > > If you start a localhost migrate, and press "Ctrl-C" in the middle, > > you get two hung domains > status: Probably not for 4.3 > > * libxl / xl does not handle failure of remote qemu gracefully > > Easiest way to reproduce: > > - set "vncunused=0" and do a local migrate > > - The "remote" qemu will fail because the vnc port is in use > > The failure isn''t the problem, but everything being stuck afterwards is > status: Probably not for 4.3 > > * mac address changes on reboot if not specified in config file > > Needs a robust way to "add" to the config > status: Too much for 4.3 > > * qxl > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 > - Uninitialized struct element in qemu > - Revert 5479961 to re-enable qxl in xl,libxl > - Option in Xen top-level to enable qxl support in qemu tree > - Fix sse2 MMIO issue > > * libxl config file > > * libxl: Don''t use RAW format for "URL"-based qdisks (e.g., rbd:rbd/foo.img) > - Figure out whether to use a generic URL or have a specific type for each one > - Check existence of disk file for all RAW > > * Polish up xenbugtool > owner: wei.liu2@citrix.com > > * acpi-related xenstore entries not propagated on migrate > > http://www.gossamer-threads.com/lists/xen/devel/282466 > > Only used by hvmloader; only a clean-up, not a bug. > status: Not for 4.3 > > * Remove hardcoded mobprobe''s in xencommons > owner: Wei Liu > status: still in discussion > > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: George > status: v6 patch series posted > > * Rationalized backend scripts > owner: roger@citrix > status: patches posted > > * Scripts for driver domains (depends on backend scripts) > owner: roger@citrix > status: > > * Multi-vector PCI MSI (support at least for Dom0) > owner: jan@suse > status: Patches posted for Intel; AMD not yet doneAnd patches for Linux upstream are missing.> > * xl: passing more defaults in configuration in xl.conf > owner: ? > 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. > > * xl PVUSB pass-through for PV guests > * xl PVUSB pass-through for HVM guests > owner: George > status: ? > xm/xend supports PVUSB pass-through to guests with PVUSB drivers > (both PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current > work-in-progress versions are in Konrad''s git tree.Which is to say I hadn''t actually touched them in a year.> - James Harper''s GPLPV drivers for Windows include PVUSB frontend drivers. > > * Guest EFI booting > - status: tianocore in-tree, some build problems. > Needs new owner. > > * Xen EFI feature: pvops dom0 able to make use of EFI run-time > services (external) > owner: Daniel Kiper > status: Just begun > > * Serial console improvements > owner: ? > status: Stalled (see below) > -xHCI debug port (Needs hardware) > -Firewire (needs hardware) >I would like also to put GPU passthrough working here.> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
> * Xen EFI feature: pvops dom0 able to make use of EFI run-time > services (external) > owner: Daniel Kiper > status: Just begunI think this is addressed, maybe in full, by this patchset, presented in the midst of getting 4.3 in order: http://lists.xen.org/archives/html/xen-devel/2013-05/msg02492.html I have used this for the last 3 months. The noted i915 issue was resolved by later updates to the kernel or X driver, as 3.10.1 is running smoothly. The only issue I have observed is that although Xen correctly powers off the system in response to a dom0-initiated shutdown, Xen is not currently rebooting - I have to let the system wind down and then do a power cycle. The patchset is an update to a set originally submitted by Tang Liang, which I gather was based on work done by Suse. Given that the patches are 100% kernel-side (the Xen code was put in place some time ago), what needs to be done for acceptance by the LKML folks? - Eric
On Thu, Aug 08, 2013 at 03:38:58PM -0400, Eric Shelton wrote:> > * Xen EFI feature: pvops dom0 able to make use of EFI run-time > > services (external) > > owner: Daniel Kiper > > status: Just begun > > I think this is addressed, maybe in full, by this patchset, presented > in the midst of getting 4.3 in order: > > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02492.html > > I have used this for the last 3 months. The noted i915 issue was > resolved by later updates to the kernel or X driver, as 3.10.1 is > running smoothly. The only issue I have observed is that although Xen > correctly powers off the system in response to a dom0-initiated > shutdown, Xen is not currently rebooting - I have to let the system > wind down and then do a power cycle. > > The patchset is an update to a set originally submitted by Tang Liang, > which I gather was based on work done by Suse. Given that the patches > are 100% kernel-side (the Xen code was put in place some time ago), > what needs to be done for acceptance by the LKML folks?Rework them. The maintainer would like it done differently - that was my recollection last year when I chatted with him (Matthew Garret). Daniel will know more - but he is right now making multiboot2 work with Xen and then attacking this.> > - Eric > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: . . .> Rework them. The maintainer would like it done differently - that was my > recollection last year when I chatted with him (Matthew Garret). > > Daniel will know more - but he is right now making multiboot2 work with > Xen and then attacking this.Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said:> Hm. Is there absolutely no way to do this by replacing efi_call_*? It''d > really be nice to avoid yet another set of duplicate functions here - > the ia64/x86 situation is already bad enough. Ideally this would be > sufficiently generic that arm can also plug into it.It looks like the arm patches are just now nearing commit worthiness, with V2 just posted a couple of days ago: https://lkml.org/lkml/2013/8/6/584 It looks like Garrett''s goal of merging arm and x86 EFI code is being realized, and that I will need to refactor my patchset to keep up with these changes. Roy Franz seems to be doing the heavy lifting on arm EFI, with Matt Fleming serving as the maintainer. Related to this, is the Xen hypervisor booting under EFI for arm already? I assume not, if Linux currently lacks the needed hypercalls. Does anything arm-specific need to happen in an EFI-friendly dom0 kernel, given that it is hypercall driven? Is there a platform for test? - Eric
>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > == Open => > * __update_vcpu_system_time if system_time comes out negativeDone since Jul 2 (5ad914bc867c5a6a4957869c89918f4e1f9dd9c4). Jan
>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > === Big ticket items ==> > * Event channel scalability > owner: david@citrix > status: RFC v5 submittedThat was Wei''s variant I believe; I don''t think David''s has reached v5 yet.> * Default to credit2Was that really the plan? * Multi-vector MSI (deferred from 4.3, now done) Jan
>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > === clean-ups ==> > * Implement Xen hypervisor dmesg log entry timestampsIsn''t that what the "console_timestamps" command line option already does? Or if not, what is this about?> * Multi-vector PCI MSI (support at least for Dom0) > owner: jan@suse > status: Patches posted for Intel; AMD not yet doneOh, this was listed under cleanups. Anyway - it''s done (also for AMD). Jan
>>> On 08.08.13 at 18:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 08/08/13 17:14, George Dunlap wrote: >>> * qxl >>> > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >>> - Uninitialized struct element in qemu >>> - Revert 5479961 to re-enable qxl in xl,libxl >>> - Option in Xen top-level to enable qxl support in qemu tree >>> - Fix sse2 MMIO issue >> qxl has been re-enabled, but we still haven''t had anyone step up to >> implement >8-byte IO instructions. Any takers? >> >> -George > > Not that I have time to look at this, but can this requirement include > support for 32 byte IO instructions, to allow for AVX emulation as well > as just SSE.If anything, we should make this arbitrary size anyway. AVX-512 is already at the horizon. Jan
>>> On 08.08.13 at 18:11, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: >> * blktap3 >> owner: thanos@citrix >> status: on hold pending XenServer decision > > Sorry, missed this one -- this is more or less cancelled.So is there any supposed replacement then? Jan
On ven, 2013-08-09 at 09:02 +0100, Jan Beulich wrote:> > * Default to credit2 > > Was that really the plan? >We want to do that at some point, yes, although, most likely, not for 4.4, right George? 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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On ven, 2013-08-09 at 09:11 +0100, Jan Beulich wrote:> >>> On 08.08.13 at 18:11, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > > On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > > <George.Dunlap@eu.citrix.com> wrote: > >> * blktap3 > >> owner: thanos@citrix > >> status: on hold pending XenServer decision > > > > Sorry, missed this one -- this is more or less cancelled. > > So is there any supposed replacement then? >AFAIUI, that is using (and improving) qdisk for all the (previous) blktap use cases: http://lists.xen.org/archives/html/xen-devel/2013-07/msg02433.html 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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote:> = Timeline > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 >18 October... Tight. At least code freeze is a bit later! :-P> Last updated: 8 August 2013 > > == Backlog => > === Testing coverage ==> > [..] >* Performance benchmarking on top of osstest @dario> === Big ticket items ==> > * NUMA Memory migration > owner: dario@citrix > status: in progress >Confirmed to be in progress.> * Meta: PVIO NUMA improvements > - NUMA affinity for vcpus > owner: Dario >status: in progress> - PV guest NUMA interface > owner: Elena >status: in progress Right Elena?> - Sensible dom0 NUMA layout >status: not started> - Toolstack pinning backend thread / virq to appropraite d0 vcpu >status: not started Also, we might want to add: - HVM guest NUMA owner: Matt Wilson status: ? Is that ok, Matt? If you''re concerned about the libxl part of that, I have a series half backed that I''ll be posting here soon (as RFC or something), so feel free to leave that to me. :-) And this one too: - NUMA-aware ballooning owner: Li Yechen status: ? Is that ok, Yechen?> * libvirt/libxl integration (external) > > need a status update > - owner: jfehlig@suse, dario@citrix >Yep, putting together a status update right in these days (I plan a XenSummit talk about it)> === clean-ups ==> > * Sort out better memory / ballooning / dom0 autoballooning thing > > Don''t forget NUMA angle >Mmm... This is an old discussion which, if I remember correctly (at least what the "NUMA angle" was), is about a TOCTOU issue involving automatic NUMA placement and ballooning, domain creation, and perhaps even more memory related operations (depends on the toolstack)... It''s not "just" a ballooning or autoballooning problem, and it''s completely different from the "NUMA-aware ballooning" I was talking about before. I don''t have much in mind to properly deal with it. One think I can double check is whether the claim mechanism Oracle introduced can be of any help, but nothing much than that for now. In any case, at least from my side, this is as follows. status: not started. Regards, 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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, Aug 08, 2013 at 04:51:51PM -0400, Eric Shelton wrote:> On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > . . . > > Rework them. The maintainer would like it done differently - that was my > > recollection last year when I chatted with him (Matthew Garret). > > > > Daniel will know more - but he is right now making multiboot2 work with > > Xen and then attacking this. > > Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said: > > > Hm. Is there absolutely no way to do this by replacing efi_call_*? It''d > > really be nice to avoid yet another set of duplicate functions here - > > the ia64/x86 situation is already bad enough. Ideally this would be > > sufficiently generic that arm can also plug into it. > > It looks like the arm patches are just now nearing commit worthiness, > with V2 just posted a couple of days ago: > > https://lkml.org/lkml/2013/8/6/584 > > It looks like Garrett''s goal of merging arm and x86 EFI code is being > realized, and that I will need to refactor my patchset to keep up with > these changes. Roy Franz seems to be doing the heavy lifting on arm > EFI, with Matt Fleming serving as the maintainer.I have not dug very deep but it looks that it is only EFI loader patch series (called stub in Linux Kernel). It is not related to Xen EFI stuff in Linux Kernel.> Related to this, is the Xen hypervisor booting under EFI for arm > already? I assume not, if Linux currently lacks the needed > hypercalls. Does anything arm-specific need to happen in an > EFI-friendly dom0 kernel, given that it is hypercall driven? Is there > a platform for test?IIRC there is no EFI support in Xen on ARM. However, you should ask Stefano and/or Ian Campbell for more details. They are ARM maintainers for Xen. As Konrad said I am working on multiboot2 protocol support for Xen. It is needed to load Xen from e.g. GRUB2 loader on EFI platforms. I would like to finish this first because there are some interests in that project. Then I will be working on EFI support for Xen in Linux Kernel. However, if you like to work on this stuff go ahead. I do no have any objections. Just drop me line then I would not duplicate your efforts. Daniel
On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: [...]> * Xen EFI feature: Xen can boot from grub.efi > owner: Daniel Kiper > status: Just begun > prognosis: FairI think that you could change that to Good. I am working on it. Migration to xbi struct is almost finished and multiboot2 protocol works on machines with legacy BIOS. Now I am working on multiboot2 protocol for machines with EFI. Yesterday, I discovered some issues related to memory map passed via this protocol. Sadly it looks that taking into account current GRUB2 implementation only workaround is available. Final proper solution would require some changes in GRUB2. I will do that later. [...]> * Guest EFI booting > - status: tianocore in-tree, some build problems. > Needs new owner.I could take over ownership of this but it would have lowest priority on my task list now (major stuff only: 1 - multiboot2 protocl, 2 - EFI support for Xen in Linux Kernel, 3 - guest EFI booting).> * Xen EFI feature: pvops dom0 able to make use of EFI run-time > services (external) > owner: Daniel Kiper > status: Just begunI am going to start work on it when I finish work on multiboot2 protocol. Additionally, I think that: - new kexec implementation should be added to this list; David Vrabel work on this; I think that patches are quite mature and need only some polishing, - unmodified_drivers should be removed because as I know they are not maintained for very long time; if you agree I could do that, - as I saw there is a quite big mess in directory structure used by installed Xen related stuff (especially in /var and /usr); I have done some patches for myself but they require some improvements to do public release; if you wish I could work on this too. Have a nice weekend, Daniel
On 08/08/2013 12:09 PM, George Dunlap wrote:> * xenperf > Owner: Boris OtovskyThe first cut is almost done, I only need to get 32-bit PV working. I expect to post v1 patches after I get back from vacation (early September) -boris
On Fri, Aug 09, 2013 at 04:10:10PM +0200, Dario Faggioli wrote:> On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote: > > = Timeline > > > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > > 4.3 was released on 9 July. That would give us a release on 9 January > > 2014. This is fairly close after the Christmas season, so I propose > > to make the estimated release date later, on 21 January, giving a few > > extra weeks for the holiday season: > > > > * Feature freeze: 18 October 2013 > > * Code freezing point: 8 November 2013 > > * First RC: 26 November 2013 > > * Release: 21 January 2014 > >[...]> > === Big ticket items ==[...]> Also, we might want to add: > > - HVM guest NUMA > owner: Matt Wilson > status: ? > > Is that ok, Matt?Yes.> If you''re concerned about the libxl part of that, I have a series half > backed that I''ll be posting here soon (as RFC or something), so feel > free to leave that to me. :-)OK! I''ll try to find some time to rebase the patch and post as an RFC. --msw
On ven, 2013-08-09 at 16:08 -0700, Matt Wilson wrote:> > Also, we might want to add: > > > > - HVM guest NUMA > > owner: Matt Wilson > > status: ? > > > > Is that ok, Matt? > > Yes. > > > If you''re concerned about the libxl part of that, I have a series half > > backed that I''ll be posting here soon (as RFC or something), so feel > > free to leave that to me. :-) > > OK! I''ll try to find some time to rebase the patch and post as an RFC. >Great! Whenever you''re ready. :-) Thanks and Regards, 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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: > - unmodified_drivers should be removed because as I know > they are not maintained for very long time; if you > agree I could do that,The most recent update to them was on 2013-02-12, so not all _that_ long ago. We''re still using them, so I''d hope that they could stay in the tree, saving us from having to patch them back in. Jan
On 09/08/13 21:01, Daniel Kiper wrote:> > Additionally, I think that: > - new kexec implementation should be added to this list; > David Vrabel work on this; I think that patches are > quite mature and need only some polishing,The way it writes the page tables used to exec the image needs changing -- this is non trivial. David
On 08/08/13 17:09, George Dunlap wrote:> This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4There''s nothing on this page.> * Event channel scalability > owner: david@citrix > status: RFC v5 submitted > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests)RFC v2 of the FIFO ABI has been posted. David
On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote:> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: > > - unmodified_drivers should be removed because as I know > > they are not maintained for very long time; if you > > agree I could do that, > > The most recent update to them was on 2013-02-12, so not all > _that_ long ago. We''re still using them, so I''d hope that they > could stay in the tree, saving us from having to patch them back > in.As I understood from [1] unmodified_drivers is not maintained. However, if you found out that it was updated quite recently then I do not insist on removing it. 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html Daniel
On Mon, Aug 12, 2013 at 10:44:35AM +0100, David Vrabel wrote:> On 09/08/13 21:01, Daniel Kiper wrote: > > > > Additionally, I think that: > > - new kexec implementation should be added to this list; > > David Vrabel work on this; I think that patches are > > quite mature and need only some polishing, > > The way it writes the page tables used to exec the image needs changing > -- this is non trivial.Ugh... Could you tell more? Daniel
On Thu, 8 Aug 2013 17:09:35 +0100 George Dunlap <George.Dunlap@eu.citrix.com> wrote:> This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I''m just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I''ll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we''ll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome......> === Big ticket items ==......> * PVH mode (w/ Linux) > owner: mukesh@oracle > status (Linux): 3rd draft patches posted. > status (Xen): v10 postedWith holidays, vacation, other things on my plate i need to work on soon, the hurdles faced by V10, and still remaing tools and dom0 patch, this seems a difficult proposition for 4.4. thanks Mukesh
>>> On 12.08.13 at 20:55, Daniel Kiper <dkiper@net-space.pl> wrote: > On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote: >> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: >> > - unmodified_drivers should be removed because as I know >> > they are not maintained for very long time; if you >> > agree I could do that, >> >> The most recent update to them was on 2013-02-12, so not all >> _that_ long ago. We''re still using them, so I''d hope that they >> could stay in the tree, saving us from having to patch them back >> in. > > As I understood from [1] unmodified_drivers is not maintained. > However, if you found out that it was updated quite recently then > I do not insist on removing it. > > 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.htmlWhat I said there has nothing to do with the maintenance status of the unmodified_drivers/ subtree; instead, it is related to the need to also have a suitable forward ported Linux tree to build them against. Jan
On Tue, Aug 13, 2013 at 11:13:42AM +0100, Jan Beulich wrote:> >>> On 12.08.13 at 20:55, Daniel Kiper <dkiper@net-space.pl> wrote: > > On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote: > >> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: > >> > - unmodified_drivers should be removed because as I know > >> > they are not maintained for very long time; if you > >> > agree I could do that, > >> > >> The most recent update to them was on 2013-02-12, so not all > >> _that_ long ago. We''re still using them, so I''d hope that they > >> could stay in the tree, saving us from having to patch them back > >> in. > > > > As I understood from [1] unmodified_drivers is not maintained. > > However, if you found out that it was updated quite recently then > > I do not insist on removing it. > > > > 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html > > What I said there has nothing to do with the maintenance status > of the unmodified_drivers/ subtree; instead, it is related to the > need to also have a suitable forward ported Linux tree to build > them against.It looks that I understood your email in wrong way. Thanks for clarification. Daniel
On Thu, Aug 8, 2013 at 12:09 PM, George Dunlap <George.Dunlap@eu.citrix.com>wrote: *snip* === Testing coverage ==> *snip*> * Host S3 suspend > @bguthro > >I''m unclear on what "Testing coverage" means, in this context. Are you asking for development of a new automated test, or to manually test the release? If you mean the former, I tried to get the infrastructure up and running to run osstest before, and failed. I think I will need some help with this, from someone more familiar with the testing system, if this is what you mean. Thanks Ben _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On mar, 2013-08-13 at 09:17 -0400, Ben Guthro wrote:> *snip* > > * Host S3 suspend > @bguthro > > > > I''m unclear on what "Testing coverage" means, in this context. > Are you asking for development of a new automated test, or to manually > test the release? >The former. :-)> If you mean the former, I tried to get the infrastructure up and > running to run osstest before, and failed. >There are some stuff you have to take care of, yes. I recall succeeding in bringing it up a while back, but I don''t have the details fresh in my mind.> I think I will need some help with this, from someone more familiar > with the testing system, if this is what you mean. >Well, I will have to bring up the osstest machinery again, and I''ll start from scratch, so we can ''try together'', meaning that I''ll try (since I did it already) and let you know if I manage, so that you can try on your turn to ask questions about what''s going wrong on your side. Just know that it will be September when I''ll be doing that, since I''m about to leave for a couple of weeks. If that is not a big deal for you, we can talk more about it when I will be back. Let me know, 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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 08/08/13 17:24, Ian Campbell wrote:> On Thu, 2013-08-08 at 17:14 +0100, George Dunlap wrote: >>> * qxl >>> > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >>> - Uninitialized struct element in qemu >>> - Revert 5479961 to re-enable qxl in xl,libxl >>> - Option in Xen top-level to enable qxl support in qemu tree >>> - Fix sse2 MMIO issue >> qxl has been re-enabled, > Has it? I can''t see a patch with qxl in the title after "libxl: Remove > qxl support for the 4.3 release".Oh, right -- I thought I''d seen it go in; but I guess not.> >> but we still haven''t had anyone step up to implement >8-byte IO >> instructions. Any takers? > Assuming I''m right and it hasn''t been enabled is there any reason this > shouldn''t be a prerequisite for enabling qxl?I wouldn''t think so -- I view the extended instruction support as a bug. In any case, having the qxl functionality will make an easy way for developers to test the vector instruction functionality. -George
On Tue, Aug 13, 2013 at 11:43 AM, Dario Faggioli <dario.faggioli@citrix.com>wrote:> On mar, 2013-08-13 at 09:17 -0400, Ben Guthro wrote: > > > *snip* > > > > * Host S3 suspend > > @bguthro > > > > > > > > I''m unclear on what "Testing coverage" means, in this context. > > Are you asking for development of a new automated test, or to manually > > test the release? > > > The former. :-) > > > If you mean the former, I tried to get the infrastructure up and > > running to run osstest before, and failed. > > > There are some stuff you have to take care of, yes. I recall succeeding > in bringing it up a while back, but I don''t have the details fresh in my > mind. > > > I think I will need some help with this, from someone more familiar > > with the testing system, if this is what you mean. > > > Well, I will have to bring up the osstest machinery again, and I''ll > start from scratch, so we can ''try together'', meaning that I''ll try > (since I did it already) and let you know if I manage, so that you can > try on your turn to ask questions about what''s going wrong on your side. > > Just know that it will be September when I''ll be doing that, since I''m > about to leave for a couple of weeks. If that is not a big deal for you, > we can talk more about it when I will be back. > > Let me know, >Sounds like a plan - I''ve got plenty to do between now, and then anyhow. Thanks Ben> 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) > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote:> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >> This information will be mirrored on the Xen 4.4 Roadmap wiki page: >> http://wiki.xen.org/wiki/Xen_Roadmap/4.4 >> >> Rather than try to predict precisely what will make it into what >> release (which was something of a disaster last release), I''m just >> going to borrow a term from the Agile world and call all uncompleted >> features the "Backlog". I''ll still track who is doing what, and when >> we get close, what state things seem to be in. >> >> As mentioned in another e-mail, we''ll also be working on improving the >> regression tester. Feel free to join us. >> >> And as always, if you are working on a feature / bug that you want >> tracked, please respond to this e-mail. >> >> = Timeline >> >> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >> 4.3 was released on 9 July. That would give us a release on 9 January >> 2014. This is fairly close after the Christmas season, so I propose >> to make the estimated release date later, on 21 January, giving a few >> extra weeks for the holiday season: >> >> * Feature freeze: 18 October 2013 >> * Code freezing point: 8 November 2013 >> * First RC: 26 November 2013 >> * Release: 21 January 2014 >> >> Feedback on the estimated dates is welcome. >> >> Last updated: 8 August 2013 >> >> == Completed =>> >> [none] >> >> == Open =>> >> * xend still in tree >> >> * qemu-upstream not freeing pirq >> > http://www.gossamer-threads.com/lists/xen/devel/281498 >> status: patches posted > They did fix the problem Oracle saw and I believe have been > Tested-and-Acked.Thanks -- have they also been applied?> >> * __update_vcpu_system_time if system_time comes out negative >> >> * xl pci-detach broken for pv guests? >> > http://bugs.xenproject.org/xen/bug/12 >> > kernel doesn''t know about moving into states 7 and 8 >> status: External > Didn''t I post a patch for this on Linux - and it is in Linux kernel > already.Great -- thanks for the update.>> * Race in PV shutdown between tool detection and shutdown watch >> > http://www.gossamer-threads.com/lists/xen/devel/282467 >> > Nothing to do with ACPI >> status: Probably a bug in Linux xen drivers >> >> == Backlog =>> >> === Testing coverage ==>> >> * Network driver domains >> @George >> >> * new libxl w/ previous versions of xl >> @IanJ >> >> * Host S3 suspend >> @bguthro >> >> * Default [example] XSM policy >> @Stefano to ask Daniel D >> >> * Xen on ARM >> # hardware >> @ianc >> emulator: @stefano to think about it >> >> * Storage driver domains >> @roger >> >> * HVM pci passthrough >> @anthony >> >> * Nested virt? >> @intel (chased by George) >> >> * Fix SRIOV test (chase intel) >> @ianj >> >> * Fix bisector to e-mail blame-worthy parties >> @ianj >> >> * Fix xl shutdown >> @ianj >> >> * stub domains >> @athony >> >> === Big ticket items ==>> >> * NUMA Memory migration >> owner: dario@citrix >> status: in progress >> >> * Event channel scalability >> owner: david@citrix >> status: RFC v5 submitted >> Increase limit on event channels (currently 1024 for 32-bit guests, >> 4096 for 64-bit guests) > aka FIFO thing right?Yep. I''ll make this a bit more clear.> >> * PVH mode (w/ Linux) >> owner: mukesh@oracle >> status (Linux): 3rd draft patches posted. > More like v8. And already Acked - just waiting for ABI to be in some way > "nailed down". > >> status (Xen): v10 posted >> >> * ARM stuff: ?? >> >> * Meta: PVIO NUMA improvements >> - NUMA affinity for vcpus >> owner: Dario >> - PV guest NUMA interface >> owner: Elena >> - Sensible dom0 NUMA layout >> - Toolstack pinning backend thread / virq to appropraite d0 vcpu >> >> * qemu-upstream stubdom, Linux >> owner: anthony@citrix >> status: in progress >> qemu-upstream needs a more fully-featured libc than exists in >> mini-os. Either work on a minimalist linux-based stubdom with >> glibc, or port one of the BSD libcs to minios. >> >> * qemu-upstream stubdom, BSD libc >> owner: ianj@citrix >> >> * Network performance improvements >> owner: wei@citrix >> >> * Disk performance improvements > I think you mean blkback and blkfront? >> * Xen EFI feature: Xen can boot from grub.efi >> owner: Daniel Kiper >> status: Just begun >> prognosis: Fair >> >> * libvirt/libxl integration (external) >> > need a status update >> - owner: jfehlig@suse, dario@citrix >> >> * Default to credit2 >> - cpu pinning >> - NUMA affinity >> - cpu "reservation" >> >> * xenperf >> Owner: Boris Otovsky >> >> * blktap3 >> owner: thanos@citrix >> status: on hold pending XenServer decision >> >> * Nested virtualization on Intel >> >> * Nested virtualization on AMD >> >> * Make storage migration possible >> owner: ? >> status: none >> There needs to be a way, either via command-line or via some hooks, >> that someone can build a "storage migration" feature on top of libxl >> or xl. >> >> * Full-VM snapshotting >> owner: ? >> status: none >> Have a way of coordinating the taking and restoring of VM memory and >> disk snapshots. This would involve some investigation into the best >> way to accomplish this. >> >> * VM Cloning >> owner: ? >> status: none >> Again, a way of coordinating the memory and disk aspects. Research >> into the best way to do this would probably go along with the >> snapshotting feature. >> >> * xl vm-{export,import} >> owner: ? >> status: none >> Allow xl to import and export VMs to other formats; particularly >> ovf, perhaps the XenServer format, or more. >> >> * Memory: Replace PoD with paging mechanism >> owner: george@citrix >> status: none >> >> * PV audio (audio for stubdom qemu) >> owner: stefano.panella@citrix >> status: ? >> >> * Wait queues for mm >> > Needed for more advanced paging schemes >> owner: ? >> status: Draft posted Feb 2012; more work to do. >> >> * V4V: Inter-domain communication >> owner (Xen): dominic.curran@citrix.com >> status (Xen): patches submitted >> owner (Linux driver): stefano.panella@citrix >> status (Linux driver): in progress >> >> === clean-ups ==>> >> * Sort out better memory / ballooning / dom0 autoballooning thing >> > Don''t forget NUMA angle >> - Inaccurate / incomplete info from HV >> >> * Implement Xen hypervisor dmesg log entry timestamps >> >> * Make network driver domains easier to set up / more useful >> - Default backend (submitted) >> - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted) >> - Make it easy to make a device assignable (in discussion) >> - Automatically start/shutdown (xendomains?) >> - Pause booting of other domains until network driver domain is up >> >> * libxl: More fine-grained control over when to pass through a device >> > Some IOMMUs are secure; some are merely functional, some are not present. >> > Allow the adminitrator to set the default >> >> * xl does not handle migrate interruption gracefully >> > If you start a localhost migrate, and press "Ctrl-C" in the middle, >> > you get two hung domains >> status: Probably not for 4.3 >> >> * libxl / xl does not handle failure of remote qemu gracefully >> > Easiest way to reproduce: >> > - set "vncunused=0" and do a local migrate >> > - The "remote" qemu will fail because the vnc port is in use >> > The failure isn''t the problem, but everything being stuck afterwards is >> status: Probably not for 4.3 >> >> * mac address changes on reboot if not specified in config file >> > Needs a robust way to "add" to the config >> status: Too much for 4.3 >> >> * qxl >> > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >> - Uninitialized struct element in qemu >> - Revert 5479961 to re-enable qxl in xl,libxl >> - Option in Xen top-level to enable qxl support in qemu tree >> - Fix sse2 MMIO issue >> >> * libxl config file >> >> * libxl: Don''t use RAW format for "URL"-based qdisks (e.g., rbd:rbd/foo.img) >> - Figure out whether to use a generic URL or have a specific type for each one >> - Check existence of disk file for all RAW >> >> * Polish up xenbugtool >> owner: wei.liu2@citrix.com >> >> * acpi-related xenstore entries not propagated on migrate >> > http://www.gossamer-threads.com/lists/xen/devel/282466 >> > Only used by hvmloader; only a clean-up, not a bug. >> status: Not for 4.3 >> >> * Remove hardcoded mobprobe''s in xencommons >> owner: Wei Liu >> status: still in discussion >> >> * xl USB pass-through for HVM guests using Qemu USB emulation >> owner: George >> status: v6 patch series posted >> >> * Rationalized backend scripts >> owner: roger@citrix >> status: patches posted >> >> * Scripts for driver domains (depends on backend scripts) >> owner: roger@citrix >> status: >> >> * Multi-vector PCI MSI (support at least for Dom0) >> owner: jan@suse >> status: Patches posted for Intel; AMD not yet done > And patches for Linux upstream are missing.> >> * xl: passing more defaults in configuration in xl.conf >> owner: ? >> 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. >> >> * xl PVUSB pass-through for PV guests >> * xl PVUSB pass-through for HVM guests >> owner: George >> status: ? >> xm/xend supports PVUSB pass-through to guests with PVUSB drivers >> (both PV and HVM guests). >> - port the xm/xend functionality to xl. >> - this PVUSB feature does not require support or emulation from Qemu. >> - upstream the Linux frontend/backend drivers. Current >> work-in-progress versions are in Konrad''s git tree. > Which is to say I hadn''t actually touched them in a year.Yeah, I was under the impression they weren''t really going anywhere. If you think this is unclear, feel free to suggest alternate wording.> >> - James Harper''s GPLPV drivers for Windows include PVUSB frontend drivers. >> >> * Guest EFI booting >> - status: tianocore in-tree, some build problems. >> Needs new owner. >> >> * Xen EFI feature: pvops dom0 able to make use of EFI run-time >> services (external) >> owner: Daniel Kiper >> status: Just begun >> >> * Serial console improvements >> owner: ? >> status: Stalled (see below) >> -xHCI debug port (Needs hardware) >> -Firewire (needs hardware) >> > I would like also to put GPU passthrough working here.What aspect do you mean? -George
On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote:> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >> * Multi-vector PCI MSI (support at least for Dom0) >> owner: jan@suse >> status: Patches posted for Intel; AMD not yet done > And patches for Linux upstream are missing.Jan, care to comment on this? -George
>>> On 13.08.13 at 18:22, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote: >> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >>> * Multi-vector PCI MSI (support at least for Dom0) >>> owner: jan@suse >>> status: Patches posted for Intel; AMD not yet done >> And patches for Linux upstream are missing. > > Jan, care to comment on this?As indicated to Konrad earlier - upstream code is too different from ours for me to propose a patch here. I handed Konrad the patch that I have on our kernel for future reference, and am relying on him (or someone else) to actually do that work. Jan
On mar, 2013-08-13 at 12:18 -0400, Ben Guthro wrote:> > Just know that it will be September when I''ll be doing that, > since I''m > about to leave for a couple of weeks. If that is not a big > deal for you, > we can talk more about it when I will be back. > > Let me know, > > > Sounds like a plan - I''ve got plenty to do between now, and then > anyhow. >Cool. I will let you know when done with it then. Regards, 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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 09/08/13 09:02, Jan Beulich wrote:>>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> === Big ticket items ==>> >> * Event channel scalability >> owner: david@citrix >> status: RFC v5 submitted > That was Wei''s variant I believe; I don''t think David''s has reached > v5 yet. > >> * Default to credit2 > Was that really the plan?It''s something I would really like to see in -- but as indicated, there are a couple of critical missing features, and I don''t think I''ll be able to make it for 4.4. -George
On 09/08/13 09:06, Jan Beulich wrote:>>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> === clean-ups ==>> >> * Implement Xen hypervisor dmesg log entry timestamps > Isn''t that what the "console_timestamps" command line option > already does? Or if not, what is this about?It comes from this uservoice suggestion by Pasi: https://xenorg.uservoice.com/forums/172169-xen-development/suggestions/3924048-implement-xen-hypervisor-dmesg-log-entry-timestamp Andy C. commented, saying that "console_timestamps" was a bit heavyweight, and that this (which only has seconds since boot) was more useful. I''ll update this to reflect that.>> * Multi-vector PCI MSI (support at least for Dom0) >> owner: jan@suse >> status: Patches posted for Intel; AMD not yet done > Oh, this was listed under cleanups. Anyway - it''s done (also for > AMD).Yes, sorry -- the list is getting awfully long, and I was under some pressure to get the list out, particularly as it had been over a month since the 4.3 release. I''ve re-organized stuff now and will post it to the wiki in the better-organized format. -George
On 09/08/13 15:10, Dario Faggioli wrote:> On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote: >> = Timeline >> >> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >> 4.3 was released on 9 July. That would give us a release on 9 January >> 2014. This is fairly close after the Christmas season, so I propose >> to make the estimated release date later, on 21 January, giving a few >> extra weeks for the holiday season: >> >> * Feature freeze: 18 October 2013 >> * Code freezing point: 8 November 2013 >> * First RC: 26 November 2013 >> * Release: 21 January 2014 >> > 18 October... Tight. At least code freeze is a bit later! :-P > >> Last updated: 8 August 2013 >> >> == Backlog =>> >> === Testing coverage ==>> >> [..] >> > * Performance benchmarking on top of osstest > @dario> >> === Big ticket items ==>> >> * NUMA Memory migration >> owner: dario@citrix >> status: in progress >> > Confirmed to be in progress. > >> * Meta: PVIO NUMA improvements >> - NUMA affinity for vcpus >> owner: Dario >> > status: in progress > >> - PV guest NUMA interface >> owner: Elena >> > status: in progress > > Right Elena? > >> - Sensible dom0 NUMA layout >> > status: not started > >> - Toolstack pinning backend thread / virq to appropraite d0 vcpu >> > status: not started > > Also, we might want to add: > > - HVM guest NUMA > owner: Matt Wilson > status: ? > > Is that ok, Matt? > > If you''re concerned about the libxl part of that, I have a series half > backed that I''ll be posting here soon (as RFC or something), so feel > free to leave that to me. :-) > > And this one too: > > - NUMA-aware ballooning > owner: Li Yechen > status: ? > > Is that ok, Yechen? > >> * libvirt/libxl integration (external) >> > need a status update >> - owner: jfehlig@suse, dario@citrix >> > Yep, putting together a status update right in these days (I plan a > XenSummit talk about it) > >> === clean-ups ==>> >> * Sort out better memory / ballooning / dom0 autoballooning thing >> > Don''t forget NUMA angle >> > Mmm... This is an old discussion which, if I remember correctly (at > least what the "NUMA angle" was), is about a TOCTOU issue involving > automatic NUMA placement and ballooning, domain creation, and perhaps > even more memory related operations (depends on the toolstack)... It''s > not "just" a ballooning or autoballooning problem, and it''s completely > different from the "NUMA-aware ballooning" I was talking about before. > > I don''t have much in mind to properly deal with it. One think I can > double check is whether the claim mechanism Oracle introduced can be of > any help, but nothing much than that for now. > > In any case, at least from my side, this is as follows. > > status: not started.OK -- I think there are a couple of us with it on our minds, so I''ll leave it un-claimed. When someone starts to work on it, let everyone else know, so there''s no duplicated effort. -George
On 10/08/13 00:08, Matt Wilson wrote:> On Fri, Aug 09, 2013 at 04:10:10PM +0200, Dario Faggioli wrote: >> On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote: >>> = Timeline >>> >>> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >>> 4.3 was released on 9 July. That would give us a release on 9 January >>> 2014. This is fairly close after the Christmas season, so I propose >>> to make the estimated release date later, on 21 January, giving a few >>> extra weeks for the holiday season: >>> >>> * Feature freeze: 18 October 2013 >>> * Code freezing point: 8 November 2013 >>> * First RC: 26 November 2013 >>> * Release: 21 January 2014 >>> > [...] > >>> === Big ticket items ==> [...] > >> Also, we might want to add: >> >> - HVM guest NUMA >> owner: Matt Wilson >> status: ? >> >> Is that ok, Matt? > Yes. > >> If you''re concerned about the libxl part of that, I have a series half >> backed that I''ll be posting here soon (as RFC or something), so feel >> free to leave that to me. :-) > OK! I''ll try to find some time to rebase the patch and post as an RFC.Great! -George
On 09/08/13 21:01, Daniel Kiper wrote:> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: > > [...] > >> * Xen EFI feature: Xen can boot from grub.efi >> owner: Daniel Kiper >> status: Just begun >> prognosis: Fair > I think that you could change that to Good. I am working > on it. Migration to xbi struct is almost finished and > multiboot2 protocol works on machines with legacy BIOS. > Now I am working on multiboot2 protocol for machines > with EFI. Yesterday, I discovered some issues related > to memory map passed via this protocol. Sadly it looks > that taking into account current GRUB2 implementation > only workaround is available. Final proper solution would > require some changes in GRUB2. I will do that later. > > [...] > >> * Guest EFI booting >> - status: tianocore in-tree, some build problems. >> Needs new owner. > I could take over ownership of this but it would have > lowest priority on my task list now (major stuff only: > 1 - multiboot2 protocl, 2 - EFI support for Xen in Linux > Kernel, 3 - guest EFI booting).OK -- I think for now then I''ll leave it unclaimed, so that if any other enterprising developers show up they can take a look at it.> >> * Xen EFI feature: pvops dom0 able to make use of EFI run-time >> services (external) >> owner: Daniel Kiper >> status: Just begun > I am going to start work on it when I finish work on multiboot2 protocol. > > Additionally, I think that: > - new kexec implementation should be added to this list; > David Vrabel work on this; I think that patches are > quite mature and need only some polishing, > - unmodified_drivers should be removed because as I know > they are not maintained for very long time; if you > agree I could do that, > - as I saw there is a quite big mess in directory structure > used by installed Xen related stuff (especially in /var > and /usr); I have done some patches for myself but they > require some improvements to do public release; if you wish > I could work on this too.It''s up to you really -- if you are set on working on it, I''ll put it on the list; but there is plenty to do othewise. :-) What kinds of changes did you have in mind in particular? -George
On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4This page is now actually populated, with updates from people''s responses. -George
>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014So I didn''t see any comments on the proposed schedule so far. Hence I wonder how fixed we have to consider that plan at this point. I''m asking because from the very beginning I was not really in favor of shortening the release cycle, and looking at the number of (smaller) items on my todo list, I don''t see any way to even get just a good part of them done by the proposed feature freeze date (taking into consideration that working on those items usually is possible only when no other bugs or routine work need dealing with). Jan
On 08/09/2013 02:56 PM, Daniel Kiper wrote:> On Thu, Aug 08, 2013 at 04:51:51PM -0400, Eric Shelton wrote: >> On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk >> <konrad.wilk@oracle.com> wrote: >> . . . >>> Rework them. The maintainer would like it done differently - that was my >>> recollection last year when I chatted with him (Matthew Garret). >>> >>> Daniel will know more - but he is right now making multiboot2 work with >>> Xen and then attacking this. >> >> Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said: >> >>> Hm. Is there absolutely no way to do this by replacing efi_call_*? It''d >>> really be nice to avoid yet another set of duplicate functions here - >>> the ia64/x86 situation is already bad enough. Ideally this would be >>> sufficiently generic that arm can also plug into it. >> >> It looks like the arm patches are just now nearing commit worthiness, >> with V2 just posted a couple of days ago: >> >> https://lkml.org/lkml/2013/8/6/584 >> >> It looks like Garrett''s goal of merging arm and x86 EFI code is being >> realized, and that I will need to refactor my patchset to keep up with >> these changes. Roy Franz seems to be doing the heavy lifting on arm >> EFI, with Matt Fleming serving as the maintainer. > > I have not dug very deep but it looks that it is only EFI loader > patch series (called stub in Linux Kernel). It is not related to > Xen EFI stuff in Linux Kernel.That looks correct. The only file in common between the two sets of patches is include/linux/efi.h, and those changes do not affect each other.>> Related to this, is the Xen hypervisor booting under EFI for arm >> already? I assume not, if Linux currently lacks the needed >> hypercalls. Does anything arm-specific need to happen in an >> EFI-friendly dom0 kernel, given that it is hypercall driven? Is there >> a platform for test? > > IIRC there is no EFI support in Xen on ARM. However, you should ask > Stefano and/or Ian Campbell for more details. They are ARM maintainers > for Xen. > > As Konrad said I am working on multiboot2 protocol support for Xen. > It is needed to load Xen from e.g. GRUB2 loader on EFI platforms. > I would like to finish this first because there are some interests > in that project. Then I will be working on EFI support for Xen > in Linux Kernel. However, if you like to work on this stuff go > ahead. I do no have any objections. Just drop me line then I would > not duplicate your efforts.In the interest of getting a more finalized patch out while I still recall some of the details of this, please find below a revised patch. There continues to be an issue with reboot working on my laptop, but I think it is in the hypervisor, as the kernel is making the hypercall requesting the reboot. Unfortunately, I do not have the tools to debug Xen on my laptop, as it lacks a serial port and I do not have a few of the things needed for EHCI port debugging. The kernel reboots just fine when running directly under EFI, although I do not know right now if it is via the EFI runtime or the more traditional reboot mechanisms. If there are no comments, I will try running this by the Linux EFI maintainer. ============ From: Eric Shelton <eshelton@pobox.com> Date: Thu, 15 Aug 2013 00:31:08 -0400 Subject: [PATCH 1/1] EFI stub: add support for boot under EFI-booted Xen Allows dom0 kernel to detect when it is running under a Xen hypervisor booted under EFI, and then make hyper calls to Xen to identify and obtain resources such as ACPI tables, E820 information, and the EFI console in order to complete booting. Applies cleanly against 3.11rc5 and recent arm efi patches. Signed-off-by: Eric Shelton <eshelton@pobox.com> --- arch/x86/platform/efi/Makefile | 3 + arch/x86/platform/efi/efi.c | 82 ++++++-- arch/x86/platform/efi/xen.c | 427 +++++++++++++++++++++++++++++++++++++++ arch/x86/xen/enlighten.c | 22 +- include/linux/efi.h | 8 + include/xen/interface/platform.h | 132 ++++++++++++ 6 files changed, 649 insertions(+), 25 deletions(-) create mode 100644 arch/x86/platform/efi/xen.c diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile index 6db1cc4..f485766 100644 --- a/arch/x86/platform/efi/Makefile +++ b/arch/x86/platform/efi/Makefile @@ -1,2 +1,5 @@ obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o +#ifdef CONFIG_XEN +obj-$(CONFIG_EFI) += xen.o +#endif obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 90f6ed1..ca043bda 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -12,6 +12,7 @@ * Bibo Mao <bibo.mao@intel.com> * Chandramouli Narayanan <mouli@linux.intel.com> * Huang Ying <ying.huang@intel.com> + * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com> * * Copied from efi_32.c to eliminate the duplicated code between EFI * 32/64 support code. --ying 2007-10-26 @@ -51,6 +52,12 @@ #include <asm/x86_init.h> #include <asm/rtc.h> +#ifdef CONFIG_XEN +extern void efi_init_xen(void); +extern u32 efi_mem_type_xen(unsigned long phys_addr); +extern u64 efi_mem_attributes_xen(unsigned long phys_addr); +#endif + #define EFI_DEBUG 1 #define EFI_MIN_RESERVE 5120 @@ -381,6 +388,11 @@ int __init efi_memblock_x86_reserve_range(void) struct efi_info *e = &boot_params.efi_info; unsigned long pmap; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return 0; +#endif + #ifdef CONFIG_X86_32 /* Can''t handle data above 4GB at this time */ if (e->efi_memmap_hi) { @@ -409,6 +421,8 @@ static void __init print_efi_memmap(void) void *p; int i; + if (memmap.map == NULL) return; + for (p = memmap.map, i = 0; p < memmap.map_end; p += memmap.desc_size, i++) { @@ -426,6 +440,11 @@ void __init efi_reserve_boot_services(void) { void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) { efi_memory_desc_t *md = p; u64 start = md->phys_addr; @@ -467,6 +486,11 @@ void __init efi_free_boot_services(void) { void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + if (!efi_is_native()) return; @@ -578,20 +602,15 @@ static int __init efi_systab_init(void *phys) return 0; } -static int __init efi_config_init(u64 tables, int nr_tables) +int __init efi_config_init(u64 tables, int nr_tables, int entrySz) { void *config_tables, *tablep; - int i, sz; - - if (efi_enabled(EFI_64BIT)) - sz = sizeof(efi_config_table_64_t); - else - sz = sizeof(efi_config_table_32_t); + int i; /* * Let''s see what config tables the firmware passed to us. */ - config_tables = early_ioremap(tables, nr_tables * sz); + config_tables = early_ioremap(tables, nr_tables * entrySz); if (config_tables == NULL) { pr_err("Could not map Configuration table!\n"); return -ENOMEM; @@ -599,7 +618,7 @@ static int __init efi_config_init(u64 tables, int nr_tables) tablep = config_tables; pr_info(""); - for (i = 0; i < efi.systab->nr_tables; i++) { + for (i = 0; i < nr_tables; i++) { efi_guid_t guid; unsigned long table; @@ -612,8 +631,7 @@ static int __init efi_config_init(u64 tables, int nr_tables) if (table64 >> 32) { pr_cont("\n"); pr_err("Table located above 4GB, disabling EFI.\n"); - early_iounmap(config_tables, - efi.systab->nr_tables * sz); + early_iounmap(config_tables, nr_tables * entrySz); return -EINVAL; } #endif @@ -645,10 +663,10 @@ static int __init efi_config_init(u64 tables, int nr_tables) efi.uga = table; pr_cont(" UGA=0x%lx ", table); } - tablep += sz; + tablep += entrySz; } pr_cont("\n"); - early_iounmap(config_tables, efi.systab->nr_tables * sz); + early_iounmap(config_tables, nr_tables * entrySz); return 0; } @@ -708,9 +726,16 @@ void __init efi_init(void) { efi_char16_t *c16; char vendor[100] = "unknown"; - int i = 0; + int entrySz, i = 0; void *tmp; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) { + efi_init_xen(); + return; + } +#endif + #ifdef CONFIG_X86_32 if (boot_params.efi_info.efi_systab_hi || boot_params.efi_info.efi_memmap_hi) { @@ -745,7 +770,12 @@ void __init efi_init(void) efi.systab->hdr.revision >> 16, efi.systab->hdr.revision & 0xffff, vendor); - if (efi_config_init(efi.systab->tables, efi.systab->nr_tables)) + if (efi_enabled(EFI_64BIT)) + entrySz = sizeof(efi_config_table_64_t); + else + entrySz = sizeof(efi_config_table_32_t); + + if (efi_config_init(efi.systab->tables, efi.systab->nr_tables, entrySz)) return; set_bit(EFI_CONFIG_TABLES, &x86_efi_facility); @@ -782,7 +812,14 @@ void __init efi_init(void) void __init efi_late_init(void) { +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + +#ifdef CONFIG_ACPI_BGRT efi_bgrt_init(); +#endif } void __init efi_set_executable(efi_memory_desc_t *md, bool executable) @@ -871,6 +908,11 @@ void __init efi_enter_virtual_mode(void) void *p, *va, *new_memmap = NULL; int count = 0; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + efi.systab = NULL; /* @@ -1007,6 +1049,11 @@ u32 efi_mem_type(unsigned long phys_addr) efi_memory_desc_t *md; void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return efi_mem_type_xen(phys_addr); +#endif + if (!efi_enabled(EFI_MEMMAP)) return 0; @@ -1025,6 +1072,11 @@ u64 efi_mem_attributes(unsigned long phys_addr) efi_memory_desc_t *md; void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return efi_mem_attributes_xen(phys_addr); +#endif + for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) { md = p; if ((md->phys_addr <= phys_addr) && diff --git a/arch/x86/platform/efi/xen.c b/arch/x86/platform/efi/xen.c new file mode 100644 index 0000000..ec0943a --- /dev/null +++ b/arch/x86/platform/efi/xen.c @@ -0,0 +1,427 @@ +/* + * Xen EFI (Extensible Firmware Interface) support functions + * Based on related efforts in SLE and SUSE trees + * + * Copyright (C) 1999 VA Linux Systems + * Copyright (C) 1999 Walt Drummond <drummond@valinux.com> + * Copyright (C) 1999-2002 Hewlett-Packard Co. + * David Mosberger-Tang <davidm@hpl.hp.com> + * Stephane Eranian <eranian@hpl.hp.com> + * Copyright (C) 2005-2008 Intel Co. + * Fenghua Yu <fenghua.yu@intel.com> + * Bibo Mao <bibo.mao@intel.com> + * Chandramouli Narayanan <mouli@linux.intel.com> + * Huang Ying <ying.huang@intel.com> + * Copyright (C) 2011 Novell Co. + * Jan Beulic <JBeulich@suse.com> + * Copyright (C) 2011-2012 Oracle Co. + * Liang Tang <liang.tang@oracle.com> + * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com> + */ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/efi.h> +#include <linux/export.h> +#include <linux/platform_device.h> +#include <linux/spinlock.h> +#include <linux/time.h> + +#include <asm/setup.h> +#include <asm/efi.h> +#include <asm/time.h> +#include <asm/cacheflush.h> +#include <asm/tlbflush.h> +#include <asm/x86_init.h> + +#include <xen/interface/platform.h> +#include <xen/interface/sched.h> +#include <asm/xen/hypercall.h> + +#define PFX "EFI: " + +#define call (op.u.efi_runtime_call) +#define DECLARE_CALL(what) \ + struct xen_platform_op op; \ + op.cmd = XENPF_efi_runtime_call; \ + call.function = XEN_EFI_##what; \ + call.misc = 0 + +static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc) +{ + int err; + DECLARE_CALL(get_time); + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + if (tm) { + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time)); + memcpy(tm, &call.u.get_time.time, sizeof(*tm)); + } + + if (tc) { + tc->resolution = call.u.get_time.resolution; + tc->accuracy = call.u.get_time.accuracy; + tc->sets_to_zero = !!(call.misc & + XEN_EFI_GET_TIME_SET_CLEARS_NS); + } + + return call.status; +} + +static efi_status_t xen_efi_set_time(efi_time_t *tm) +{ + DECLARE_CALL(set_time); + + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time)); + memcpy(&call.u.set_time, tm, sizeof(*tm)); + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, + efi_bool_t *pending, + efi_time_t *tm) +{ + int err; + DECLARE_CALL(get_wakeup_time); + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + if (tm) { + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time)); + memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm)); + } + + if (enabled) + *enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED); + + if (pending) + *pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING); + + return call.status; +} + +static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm) +{ + DECLARE_CALL(set_wakeup_time); + + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time)); + if (enabled) + call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE; + if (tm) + memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm)); + else + call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY; + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_get_variable(efi_char16_t *name, + efi_guid_t *vendor, + u32 *attr, + unsigned long *data_size, + void *data) +{ + int err; + DECLARE_CALL(get_variable); + + set_xen_guest_handle(call.u.get_variable.name, name); + BUILD_BUG_ON(sizeof(*vendor) !+ sizeof(call.u.get_variable.vendor_guid)); + memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor)); + call.u.get_variable.size = *data_size; + set_xen_guest_handle(call.u.get_variable.data, data); + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *data_size = call.u.get_variable.size; + *attr = call.misc; /* misc in struction is U32 variable*/ + + return call.status; +} + +static efi_status_t xen_efi_get_next_variable(unsigned long *name_size, + efi_char16_t *name, + efi_guid_t *vendor) +{ + int err; + DECLARE_CALL(get_next_variable_name); + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + call.u.get_next_variable_name.size = *name_size; + set_xen_guest_handle(call.u.get_next_variable_name.name, name); + BUILD_BUG_ON(sizeof(*vendor) !+ sizeof(call.u.get_next_variable_name.vendor_guid)); + memcpy(&call.u.get_next_variable_name.vendor_guid, vendor, + sizeof(*vendor)); + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *name_size = call.u.get_next_variable_name.size; + memcpy(vendor, &call.u.get_next_variable_name.vendor_guid, + sizeof(*vendor)); + + return call.status; +} + +static efi_status_t xen_efi_set_variable(efi_char16_t *name, + efi_guid_t *vendor, + u32 attr, + unsigned long data_size, + void *data) +{ + DECLARE_CALL(set_variable); + + set_xen_guest_handle(call.u.set_variable.name, name); + call.misc = attr; + BUILD_BUG_ON(sizeof(*vendor) !+ sizeof(call.u.set_variable.vendor_guid)); + memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor)); + call.u.set_variable.size = data_size; + set_xen_guest_handle(call.u.set_variable.data, data); + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_query_variable_info(u32 attr, + u64 *storage_space, + u64 *remaining_space, + u64 *max_variable_size) +{ + int err; + DECLARE_CALL(query_variable_info); + + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *storage_space = call.u.query_variable_info.max_store_size; + *remaining_space = call.u.query_variable_info.remain_store_size; + *max_variable_size = call.u.query_variable_info.max_size; + + return call.status; +} + +static efi_status_t xen_efi_get_next_high_mono_count(u32 *count) +{ + int err; + DECLARE_CALL(get_next_high_monotonic_count); + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *count = call.misc; + + return call.status; +} + +static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules, + unsigned long count, + unsigned long sg_list) +{ + DECLARE_CALL(update_capsule); + + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + + set_xen_guest_handle(call.u.update_capsule.capsule_header_array, + capsules); + call.u.update_capsule.capsule_count = count; + call.u.update_capsule.sg_list = sg_list; + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules, + unsigned long count, + u64 *max_size, + int *reset_type) +{ + int err; + DECLARE_CALL(query_capsule_capabilities); + + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + + set_xen_guest_handle(call.u.query_capsule_capabilities. + capsule_header_array, capsules); + call.u.query_capsule_capabilities.capsule_count = count; + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *max_size = call.u.query_capsule_capabilities.max_capsule_size; + *reset_type = call.u.query_capsule_capabilities.reset_type; + + return call.status; +} + +#undef DECLARE_CALL +#undef call + +static void xen_efi_reset_system(int reset_type, + efi_status_t status, + unsigned long data_size, + efi_char16_t *data) +{ + struct sched_shutdown r = { .reason = SHUTDOWN_reboot }; + + if (HYPERVISOR_sched_op(SCHEDOP_shutdown, &r)) + BUG(); +} + +void __init xen_efi_probe(void) +{ + static struct xen_platform_op __initdata op = { + .cmd = XENPF_firmware_info, + .u.firmware_info = { + .type = XEN_FW_EFI_INFO, + .index = XEN_FW_EFI_CONFIG_TABLE + } + }; + + if (HYPERVISOR_dom0_op(&op) == 0) { + /* TODO: check return info */ + set_bit(EFI_XEN, &x86_efi_facility); + set_bit(EFI_BOOT, &x86_efi_facility); + /* since hypervisor calls the runtime, 32/64 bit + * EFI/kernel mismatch is not an issue. Set to + * match kernel so runtime calls will be made */ +#ifdef CONFIG_64BIT + set_bit(EFI_64BIT, &x86_efi_facility); +#endif + } +} + + +void __init efi_init_xen(void) +{ + efi_char16_t c16[100]; + char vendor[ARRAY_SIZE(c16)] = "unknown"; + int ret, i; + struct xen_platform_op op; + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; + + /* redirect system to Xen hypercall implementation */ + efi.systab = NULL, + efi.mps = EFI_INVALID_TABLE_ADDR; + efi.acpi = EFI_INVALID_TABLE_ADDR; + efi.acpi20 = EFI_INVALID_TABLE_ADDR; + efi.smbios = EFI_INVALID_TABLE_ADDR; + efi.sal_systab = EFI_INVALID_TABLE_ADDR; + efi.boot_info = EFI_INVALID_TABLE_ADDR; + efi.hcdp = EFI_INVALID_TABLE_ADDR; + efi.uga = EFI_INVALID_TABLE_ADDR; + efi.uv_systab = EFI_INVALID_TABLE_ADDR; + efi.get_time = xen_efi_get_time; + efi.set_time = xen_efi_set_time; + efi.get_wakeup_time = xen_efi_get_wakeup_time; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; + efi.set_virtual_address_map = NULL; + efi.reset_system = xen_efi_reset_system; + + /* + * Show what we know for posterity + */ + op.cmd = XENPF_firmware_info; + op.u.firmware_info.type = XEN_FW_EFI_INFO; + + op.u.firmware_info.index = XEN_FW_EFI_VENDOR; + info->vendor.bufsz = sizeof(c16); + set_xen_guest_handle(info->vendor.name, c16); + ret = HYPERVISOR_dom0_op(&op); + if (!ret) { + for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i) + vendor[i] = c16[i]; + vendor[i] = ''\0''; + } else + pr_err("Could not get the firmware vendor!\n"); + + op.u.firmware_info.index = XEN_FW_EFI_VERSION; + ret = HYPERVISOR_dom0_op(&op); + if (!ret) + pr_info("EFI-xen v%u.%.02u by %s\n", + info->version >> 16, + info->version & 0xffff, vendor); + else + pr_err("Could not get EFI revision!\n"); + + op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION; + ret = HYPERVISOR_dom0_op(&op); + if (!ret) + efi.runtime_version = info->version; + else + pr_warn(PFX "Could not get runtime services revision.\n"); + set_bit(EFI_RUNTIME_SERVICES, &x86_efi_facility); + + /* + * Let''s see what config tables the firmware passed to us. + */ + op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE; + if (HYPERVISOR_dom0_op(&op)) + BUG(); + + if (efi_config_init(info->cfg.addr, info->cfg.nent, + sizeof(efi_config_table_64_t))) + panic("Could not init EFI Configuration Tables!\n"); + set_bit(EFI_CONFIG_TABLES, &x86_efi_facility); + + /* the EFI memory info is digested by the hypervisor and + * supplied to dom0 via E820 entries */ + set_bit(EFI_MEMMAP, &x86_efi_facility); + + set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility); /* not checked */ + + /* NOTE: efi.c only does this for CONFIG_X86_32 */ + x86_platform.get_wallclock = efi_get_time; + x86_platform.set_wallclock = efi_set_rtc_mmss; +} + +/* + * Convenience functions to obtain memory types and attributes + */ +u32 efi_mem_type_xen(unsigned long phys_addr) +{ + struct xen_platform_op op; + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; + + op.cmd = XENPF_firmware_info; + op.u.firmware_info.type = XEN_FW_EFI_INFO; + op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO; + info->mem.addr = phys_addr; + info->mem.size = 0; + return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type; +} + +u64 efi_mem_attributes_xen(unsigned long phys_addr) +{ + struct xen_platform_op op; + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; + + op.cmd = XENPF_firmware_info; + op.u.firmware_info.type = XEN_FW_EFI_INFO; + op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO; + info->mem.addr = phys_addr; + info->mem.size = 0; + return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr; +} + diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 193097e..51edc64 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -32,6 +32,7 @@ #include <linux/gfp.h> #include <linux/memblock.h> #include <linux/edd.h> +#include <linux/efi.h> #include <xen/xen.h> #include <xen/events.h> @@ -1342,15 +1343,6 @@ int xen_panic_handler_init(void) return 0; } -static const struct machine_ops xen_machine_ops __initconst = { - .restart = xen_restart, - .halt = xen_machine_halt, - .power_off = xen_machine_power_off, - .shutdown = xen_machine_halt, - .crash_shutdown = xen_crash_shutdown, - .emergency_restart = xen_emergency_restart, -}; - static void __init xen_boot_params_init_edd(void) { #if IS_ENABLED(CONFIG_EDD) @@ -1493,7 +1485,12 @@ asmlinkage void __init xen_start_kernel(void) pv_mmu_ops.ptep_modify_prot_commit = xen_ptep_modify_prot_commit; } - machine_ops = xen_machine_ops; + machine_ops.restart = xen_restart; + machine_ops.halt = xen_machine_halt; + machine_ops.power_off = xen_machine_power_off; + machine_ops.shutdown = xen_machine_halt; + machine_ops.crash_shutdown = xen_crash_shutdown; + machine_ops.emergency_restart = xen_emergency_restart; /* * The only reliable way to retain the initial address of the @@ -1613,6 +1610,11 @@ asmlinkage void __init xen_start_kernel(void) xen_setup_runstate_info(0); +#ifdef CONFIG_EFI + if (xen_initial_domain()) + xen_efi_probe(); +#endif + /* Start the world */ #ifdef CONFIG_X86_32 i386_start_kernel(); diff --git a/include/linux/efi.h b/include/linux/efi.h index 5f8f176..2781dea 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -84,7 +84,10 @@ typedef struct { #define EFI_PAL_CODE 13 #define EFI_MAX_MEMORY_TYPE 14 +#define EFI_INVALID_TYPE 0xffffffff + /* Attribute values: */ +#define EFI_INVALID_ATTRIBUTE ((u64)0x0000000000000000ULL) /* invalid attribute */ #define EFI_MEMORY_UC ((u64)0x0000000000000001ULL) /* uncached */ #define EFI_MEMORY_WC ((u64)0x0000000000000002ULL) /* write-coalescing */ #define EFI_MEMORY_WT ((u64)0x0000000000000004ULL) /* write-through */ @@ -597,6 +600,10 @@ extern void efi_initialize_iomem_resources(struct resource *code_resource, extern void efi_get_time(struct timespec *now); extern int efi_set_rtc_mmss(const struct timespec *now); extern void efi_reserve_boot_services(void); +#ifdef CONFIG_XEN +extern int __init efi_config_init(u64 tables, int nr_tables, int entrySz); +extern void xen_efi_probe(void); +#endif extern struct efi_memory_map memmap; /** @@ -634,6 +641,7 @@ extern int __init efi_setup_pcdp_console(char *); #define EFI_RUNTIME_SERVICES 3 /* Can we use runtime services? */ #define EFI_MEMMAP 4 /* Can we use EFI memory map? */ #define EFI_64BIT 5 /* Is the firmware 64-bit? */ +#define EFI_XEN 6 /* Must we access EFI via Xen? */ #ifdef CONFIG_EFI # ifdef CONFIG_X86 diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h index c57d5f6..d005f0b 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -108,10 +108,111 @@ struct xenpf_platform_quirk { }; DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); +#define XENPF_efi_runtime_call 49 +#define XEN_EFI_get_time 1 +#define XEN_EFI_set_time 2 +#define XEN_EFI_get_wakeup_time 3 +#define XEN_EFI_set_wakeup_time 4 +#define XEN_EFI_get_next_high_monotonic_count 5 +#define XEN_EFI_get_variable 6 +#define XEN_EFI_set_variable 7 +#define XEN_EFI_get_next_variable_name 8 +#define XEN_EFI_query_variable_info 9 +#define XEN_EFI_query_capsule_capabilities 10 +#define XEN_EFI_update_capsule 11 + +struct xenpf_efi_runtime_call { + uint32_t function; + /* + * This field is generally used for per sub-function flags (defined + * below), except for the XEN_EFI_get_next_high_monotonic_count case, + * where it holds the single returned value. + */ + uint32_t misc; + unsigned long status; + union { +#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001 + struct { + struct xenpf_efi_time { + uint16_t year; + uint8_t month; + uint8_t day; + uint8_t hour; + uint8_t min; + uint8_t sec; + uint32_t ns; + int16_t tz; + uint8_t daylight; + } time; + uint32_t resolution; + uint32_t accuracy; + } get_time; + + struct xenpf_efi_time set_time; + +#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001 +#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002 + struct xenpf_efi_time get_wakeup_time; + +#define XEN_EFI_SET_WAKEUP_TIME_ENABLE 0x00000001 +#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002 + struct xenpf_efi_time set_wakeup_time; + +#define XEN_EFI_VARIABLE_NON_VOLATILE 0x00000001 +#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002 +#define XEN_EFI_VARIABLE_RUNTIME_ACCESS 0x00000004 + struct { + GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ + unsigned long size; + GUEST_HANDLE(void) data; + struct xenpf_efi_guid { + uint32_t data1; + uint16_t data2; + uint16_t data3; + uint8_t data4[8]; + } vendor_guid; + } get_variable, set_variable; + + struct { + unsigned long size; + GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ + struct xenpf_efi_guid vendor_guid; + } get_next_variable_name; + + struct { + uint32_t attr; + uint64_t max_store_size; + uint64_t remain_store_size; + uint64_t max_size; + } query_variable_info; + + struct { + GUEST_HANDLE(void) capsule_header_array; + unsigned long capsule_count; + uint64_t max_capsule_size; + unsigned int reset_type; + } query_capsule_capabilities; + + struct { + GUEST_HANDLE(void) capsule_header_array; + unsigned long capsule_count; + uint64_t sg_list; /* machine address */ + } update_capsule; + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call); + #define XENPF_firmware_info 50 #define XEN_FW_DISK_INFO 1 /* from int 13 AH=08/41/48 */ #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ #define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=4f15 */ +#define XEN_FW_EFI_INFO 4 /* from EFI */ +#define XEN_FW_EFI_VERSION 0 +#define XEN_FW_EFI_CONFIG_TABLE 1 +#define XEN_FW_EFI_VENDOR 2 +#define XEN_FW_EFI_MEM_INFO 3 +#define XEN_FW_EFI_RT_VERSION 4 +#define XEN_FW_EFI_PCI_ROM 5 #define XEN_FW_KBD_SHIFT_FLAGS 5 /* Int16, Fn02: Get keyboard shift flags. */ struct xenpf_firmware_info { /* IN variables. */ @@ -143,6 +244,36 @@ struct xenpf_firmware_info { /* must refer to 128-byte buffer */ GUEST_HANDLE(uchar) edid; } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ + union xenpf_efi_info { + uint32_t version; + struct { + uint64_t addr; /* EFI_CONFIGURATION_TABLE */ + uint32_t nent; + } cfg; + struct { + uint32_t revision; + uint32_t bufsz; /* input, in bytes */ + GUEST_HANDLE(void) name; + /* UCS-2/UTF-16 string */ + } vendor; + struct { + uint64_t addr; + uint64_t size; + uint64_t attr; + uint32_t type; + } mem; + struct { + /* IN variables */ + uint16_t segment; + uint8_t bus; + uint8_t devfn; + uint16_t vendor; + uint16_t devid; + /* OUT variables */ + uint64_t address; + xen_ulong_t size; + } pci_rom; + } efi_info; /* XEN_FW_EFI_INFO */ uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */ } u; @@ -361,6 +492,7 @@ struct xen_platform_op { struct xenpf_read_memtype read_memtype; struct xenpf_microcode_update microcode; struct xenpf_platform_quirk platform_quirk; + struct xenpf_efi_runtime_call efi_runtime_call; struct xenpf_firmware_info firmware_info; struct xenpf_enter_acpi_sleep enter_acpi_sleep; struct xenpf_change_freq change_freq; -- 1.8.3.4
On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: [...]> > * Polish up xenbugtool > owner: wei.liu2@citrix.com >I''ve written a rather primitive prototype and promoted it to some users some time ago unfortunately they didn''t seem to report back.> * Remove hardcoded mobprobe''s in xencommons > owner: Wei Liu > status: still in discussion >Have we not reached conclusion here? IIRC in a engineering meeting we had you said we could just leave it as-is for now? Wei.
>>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote: > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >> * Remove hardcoded mobprobe''s in xencommons >> owner: Wei Liu >> status: still in discussion >> > > Have we not reached conclusion here? IIRC in a engineering meeting we > had you said we could just leave it as-is for now???? Didn''t we long ago agree that this hard coded loading is bogus and hence should go away? Remember this was originally planned to happen for 4.3, so any change in direction here needs a very good reason imo. Jan
On Thu, Aug 15, 2013 at 02:08:01PM +0100, Jan Beulich wrote:> >>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote: > > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: > >> * Remove hardcoded mobprobe''s in xencommons > >> owner: Wei Liu > >> status: still in discussion > >> > > > > Have we not reached conclusion here? IIRC in a engineering meeting we > > had you said we could just leave it as-is for now? > > ??? Didn''t we long ago agree that this hard coded loading is bogus > and hence should go away? Remember this was originally planned > to happen for 4.3, so any change in direction here needs a very > good reason imo. >Actually I wasn''t completely sure I remembered the right thing. I might be wrong about the conclusion. Geroge, do you have any clue? :-) Wei.> Jan
Konrad Rzeszutek Wilk
2013-Aug-15 14:12 UTC
Is: Linux-EFI code to call Xen''s EFI hypercalls [RFC PATCH comments] Was:Re: Xen 4.4 development update
On Thu, Aug 15, 2013 at 01:32:12AM -0400, Eric Shelton wrote:> On 08/09/2013 02:56 PM, Daniel Kiper wrote: > >On Thu, Aug 08, 2013 at 04:51:51PM -0400, Eric Shelton wrote: > >>On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk > >><konrad.wilk@oracle.com> wrote: > >>. . . > >>>Rework them. The maintainer would like it done differently - that was my > >>>recollection last year when I chatted with him (Matthew Garret). > >>> > >>>Daniel will know more - but he is right now making multiboot2 work with > >>>Xen and then attacking this. > >> > >>Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said: > >> > >>>Hm. Is there absolutely no way to do this by replacing efi_call_*? It''d > >>>really be nice to avoid yet another set of duplicate functions here - > >>>the ia64/x86 situation is already bad enough. Ideally this would be > >>>sufficiently generic that arm can also plug into it. > >> > >>It looks like the arm patches are just now nearing commit worthiness, > >>with V2 just posted a couple of days ago: > >> > >>https://lkml.org/lkml/2013/8/6/584 > >> > >>It looks like Garrett''s goal of merging arm and x86 EFI code is being > >>realized, and that I will need to refactor my patchset to keep up with > >>these changes. Roy Franz seems to be doing the heavy lifting on arm > >>EFI, with Matt Fleming serving as the maintainer. > > > >I have not dug very deep but it looks that it is only EFI loader > >patch series (called stub in Linux Kernel). It is not related to > >Xen EFI stuff in Linux Kernel. > > That looks correct. The only file in common between the two sets of > patches is include/linux/efi.h, and those changes do not affect each > other. > > >>Related to this, is the Xen hypervisor booting under EFI for arm > >>already? I assume not, if Linux currently lacks the needed > >>hypercalls. Does anything arm-specific need to happen in an > >>EFI-friendly dom0 kernel, given that it is hypercall driven? Is there > >>a platform for test? > > > >IIRC there is no EFI support in Xen on ARM. However, you should ask > >Stefano and/or Ian Campbell for more details. They are ARM maintainers > >for Xen. > > > >As Konrad said I am working on multiboot2 protocol support for Xen. > >It is needed to load Xen from e.g. GRUB2 loader on EFI platforms. > >I would like to finish this first because there are some interests > >in that project. Then I will be working on EFI support for Xen > >in Linux Kernel. However, if you like to work on this stuff go > >ahead. I do no have any objections. Just drop me line then I would > >not duplicate your efforts. > > In the interest of getting a more finalized patch out while I still > recall some of the details of this, please find below a revised > patch. There continues to be an issue with reboot working on my > laptop, but I think it is in the hypervisor, as the kernel is making > the hypercall requesting the reboot. Unfortunately, I do not have > the tools to debug Xen on my laptop, as it lacks a serial port and I > do not have a few of the things needed for EHCI port debugging. The > kernel reboots just fine when running directly under EFI, although I > do not know right now if it is via the EFI runtime or the more > traditional reboot mechanisms. > > If there are no comments, I will try running this by the Linux EFI > maintainer.First of, thank you for taking a stab at it and redoing it. Some general comments: - the #ifdef CONFIG_XEN is generaly frowend upon. If you need them they should be in header files. The exception is the CONFIG_X86 and CONFIG_X86_64. Now said that there are other instances of code where it is sprinkled with #ifdef CONFIG_ACPI .. #ifdef CONFIG_PCI, and so on. It would have been nice if all of that got moved to a header file but in reality that could make it just more confusing. Enough about that - what I want to say is that doing #idef CONFIG_XEN is something we have been trying the utmost to not put in generic code. The reasoning is that instead of using the API (so for example if we have an generic layer and then there are platform related drivers - we want to implement the stuff in the platform drivers - not add side-channels for a specific platform). - Is there any way to move the bulk of the hypercalls in the efi_runtime services. Meaning alter the efi_runtime services to do hypercalls instead of EFI calls? That way I would think most of the EFI general logic would be untouched? This is going back to the first comment - you would want to leave as much generic code untouched as possible. And implement the bulk of the code in the platform specific code. - When approaching Matthew I would suggest you label it as RFC - to get an idea of how he would like it done - as I don''t think he will take the patch as is. He might suggest the thing I just mentioned above. Or perhaps make most of the ''efi_*'' calls go through some form of function table that by default is set to baremetal_efi_calls (see x86_init.c) - There are some code paths that just do: if (xen) return; But it is not clear why that is so (missing comments). This is needed b/c if somebody wants to redo the code in the future they would need to know where to place that ''if (xen) do something different'' - You want to credit Jan Beulich in the commit description saying that the patch was derieved from the work that he did for SuSE Linux. Liang Tang took some of that - but he forgot to mention that in the initial post. - It is unclear to me why the machine_ops assigment has been changed? Thank you again for taking a stab at it! I know that getting push back on patches is not a thing that anybody likes - but the end goal is make it be fantastic and sometimes that takes a couple of rounds (or about a dozen as my first patches for Linux took that many revisions)> > ============> > From: Eric Shelton <eshelton@pobox.com> > Date: Thu, 15 Aug 2013 00:31:08 -0400 > Subject: [PATCH 1/1] EFI stub: add support for boot under EFI-booted Xen > > Allows dom0 kernel to detect when it is running under a Xen > hypervisor booted under EFI, and then make hyper calls to Xen to > identify and obtain resources such as ACPI tables, E820 information, > and the EFI console in order to complete booting. > > Applies cleanly against 3.11rc5 and recent arm efi patches. > > Signed-off-by: Eric Shelton <eshelton@pobox.com> > --- > arch/x86/platform/efi/Makefile | 3 + > arch/x86/platform/efi/efi.c | 82 ++++++-- > arch/x86/platform/efi/xen.c | 427 > +++++++++++++++++++++++++++++++++++++++ > arch/x86/xen/enlighten.c | 22 +- > include/linux/efi.h | 8 + > include/xen/interface/platform.h | 132 ++++++++++++ > 6 files changed, 649 insertions(+), 25 deletions(-) > create mode 100644 arch/x86/platform/efi/xen.c > > diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile > index 6db1cc4..f485766 100644 > --- a/arch/x86/platform/efi/Makefile > +++ b/arch/x86/platform/efi/Makefile > @@ -1,2 +1,5 @@ > obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o > +#ifdef CONFIG_XEN > +obj-$(CONFIG_EFI) += xen.o > +#endif > obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c > index 90f6ed1..ca043bda 100644 > --- a/arch/x86/platform/efi/efi.c > +++ b/arch/x86/platform/efi/efi.c > @@ -12,6 +12,7 @@ > * Bibo Mao <bibo.mao@intel.com> > * Chandramouli Narayanan <mouli@linux.intel.com> > * Huang Ying <ying.huang@intel.com> > + * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com> > * > * Copied from efi_32.c to eliminate the duplicated code between EFI > * 32/64 support code. --ying 2007-10-26 > @@ -51,6 +52,12 @@ > #include <asm/x86_init.h> > #include <asm/rtc.h> > > +#ifdef CONFIG_XEN > +extern void efi_init_xen(void); > +extern u32 efi_mem_type_xen(unsigned long phys_addr); > +extern u64 efi_mem_attributes_xen(unsigned long phys_addr); > +#endif > + > #define EFI_DEBUG 1 > > #define EFI_MIN_RESERVE 5120 > @@ -381,6 +388,11 @@ int __init efi_memblock_x86_reserve_range(void) > struct efi_info *e = &boot_params.efi_info; > unsigned long pmap; > > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) > + return 0; > +#endif > + > #ifdef CONFIG_X86_32 > /* Can''t handle data above 4GB at this time */ > if (e->efi_memmap_hi) { > @@ -409,6 +421,8 @@ static void __init print_efi_memmap(void) > void *p; > int i; > > + if (memmap.map == NULL) return; > + > for (p = memmap.map, i = 0; > p < memmap.map_end; > p += memmap.desc_size, i++) { > @@ -426,6 +440,11 @@ void __init efi_reserve_boot_services(void) > { > void *p; > > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) > + return; > +#endif > + > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) { > efi_memory_desc_t *md = p; > u64 start = md->phys_addr; > @@ -467,6 +486,11 @@ void __init efi_free_boot_services(void) > { > void *p; > > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) > + return; > +#endif > + > if (!efi_is_native()) > return; > > @@ -578,20 +602,15 @@ static int __init efi_systab_init(void *phys) > return 0; > } > > -static int __init efi_config_init(u64 tables, int nr_tables) > +int __init efi_config_init(u64 tables, int nr_tables, int entrySz) > { > void *config_tables, *tablep; > - int i, sz; > - > - if (efi_enabled(EFI_64BIT)) > - sz = sizeof(efi_config_table_64_t); > - else > - sz = sizeof(efi_config_table_32_t); > + int i; > > /* > * Let''s see what config tables the firmware passed to us. > */ > - config_tables = early_ioremap(tables, nr_tables * sz); > + config_tables = early_ioremap(tables, nr_tables * entrySz); > if (config_tables == NULL) { > pr_err("Could not map Configuration table!\n"); > return -ENOMEM; > @@ -599,7 +618,7 @@ static int __init efi_config_init(u64 tables, > int nr_tables) > > tablep = config_tables; > pr_info(""); > - for (i = 0; i < efi.systab->nr_tables; i++) { > + for (i = 0; i < nr_tables; i++) { > efi_guid_t guid; > unsigned long table; > > @@ -612,8 +631,7 @@ static int __init efi_config_init(u64 tables, > int nr_tables) > if (table64 >> 32) { > pr_cont("\n"); > pr_err("Table located above 4GB, disabling EFI.\n"); > - early_iounmap(config_tables, > - efi.systab->nr_tables * sz); > + early_iounmap(config_tables, nr_tables * entrySz); > return -EINVAL; > } > #endif > @@ -645,10 +663,10 @@ static int __init efi_config_init(u64 tables, > int nr_tables) > efi.uga = table; > pr_cont(" UGA=0x%lx ", table); > } > - tablep += sz; > + tablep += entrySz; > } > pr_cont("\n"); > - early_iounmap(config_tables, efi.systab->nr_tables * sz); > + early_iounmap(config_tables, nr_tables * entrySz); > return 0; > } > > @@ -708,9 +726,16 @@ void __init efi_init(void) > { > efi_char16_t *c16; > char vendor[100] = "unknown"; > - int i = 0; > + int entrySz, i = 0; > void *tmp; > > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) { > + efi_init_xen(); > + return; > + } > +#endif > + > #ifdef CONFIG_X86_32 > if (boot_params.efi_info.efi_systab_hi || > boot_params.efi_info.efi_memmap_hi) { > @@ -745,7 +770,12 @@ void __init efi_init(void) > efi.systab->hdr.revision >> 16, > efi.systab->hdr.revision & 0xffff, vendor); > > - if (efi_config_init(efi.systab->tables, efi.systab->nr_tables)) > + if (efi_enabled(EFI_64BIT)) > + entrySz = sizeof(efi_config_table_64_t); > + else > + entrySz = sizeof(efi_config_table_32_t); > + > + if (efi_config_init(efi.systab->tables, efi.systab->nr_tables, entrySz)) > return; > > set_bit(EFI_CONFIG_TABLES, &x86_efi_facility); > @@ -782,7 +812,14 @@ void __init efi_init(void) > > void __init efi_late_init(void) > { > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) > + return; > +#endif > + > +#ifdef CONFIG_ACPI_BGRT > efi_bgrt_init(); > +#endif > } > > void __init efi_set_executable(efi_memory_desc_t *md, bool executable) > @@ -871,6 +908,11 @@ void __init efi_enter_virtual_mode(void) > void *p, *va, *new_memmap = NULL; > int count = 0; > > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) > + return; > +#endif > + > efi.systab = NULL; > > /* > @@ -1007,6 +1049,11 @@ u32 efi_mem_type(unsigned long phys_addr) > efi_memory_desc_t *md; > void *p; > > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) > + return efi_mem_type_xen(phys_addr); > +#endif > + > if (!efi_enabled(EFI_MEMMAP)) > return 0; > > @@ -1025,6 +1072,11 @@ u64 efi_mem_attributes(unsigned long phys_addr) > efi_memory_desc_t *md; > void *p; > > +#ifdef CONFIG_XEN > + if (efi_enabled(EFI_XEN)) > + return efi_mem_attributes_xen(phys_addr); > +#endif > + > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) { > md = p; > if ((md->phys_addr <= phys_addr) && > diff --git a/arch/x86/platform/efi/xen.c b/arch/x86/platform/efi/xen.c > new file mode 100644 > index 0000000..ec0943a > --- /dev/null > +++ b/arch/x86/platform/efi/xen.c > @@ -0,0 +1,427 @@ > +/* > + * Xen EFI (Extensible Firmware Interface) support functions > + * Based on related efforts in SLE and SUSE trees > + * > + * Copyright (C) 1999 VA Linux Systems > + * Copyright (C) 1999 Walt Drummond <drummond@valinux.com> > + * Copyright (C) 1999-2002 Hewlett-Packard Co. > + * David Mosberger-Tang <davidm@hpl.hp.com> > + * Stephane Eranian <eranian@hpl.hp.com> > + * Copyright (C) 2005-2008 Intel Co. > + * Fenghua Yu <fenghua.yu@intel.com> > + * Bibo Mao <bibo.mao@intel.com> > + * Chandramouli Narayanan <mouli@linux.intel.com> > + * Huang Ying <ying.huang@intel.com> > + * Copyright (C) 2011 Novell Co. > + * Jan Beulic <JBeulich@suse.com> > + * Copyright (C) 2011-2012 Oracle Co. > + * Liang Tang <liang.tang@oracle.com> > + * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com> > + */ > + > +#include <linux/kernel.h> > +#include <linux/init.h> > +#include <linux/efi.h> > +#include <linux/export.h> > +#include <linux/platform_device.h> > +#include <linux/spinlock.h> > +#include <linux/time.h> > + > +#include <asm/setup.h> > +#include <asm/efi.h> > +#include <asm/time.h> > +#include <asm/cacheflush.h> > +#include <asm/tlbflush.h> > +#include <asm/x86_init.h> > + > +#include <xen/interface/platform.h> > +#include <xen/interface/sched.h> > +#include <asm/xen/hypercall.h> > + > +#define PFX "EFI: " > + > +#define call (op.u.efi_runtime_call) > +#define DECLARE_CALL(what) \ > + struct xen_platform_op op; \ > + op.cmd = XENPF_efi_runtime_call; \ > + call.function = XEN_EFI_##what; \ > + call.misc = 0 > + > +static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc) > +{ > + int err; > + DECLARE_CALL(get_time); > + > + err = HYPERVISOR_dom0_op(&op); > + if (err) > + return EFI_UNSUPPORTED; > + > + if (tm) { > + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time)); > + memcpy(tm, &call.u.get_time.time, sizeof(*tm)); > + } > + > + if (tc) { > + tc->resolution = call.u.get_time.resolution; > + tc->accuracy = call.u.get_time.accuracy; > + tc->sets_to_zero = !!(call.misc & > + XEN_EFI_GET_TIME_SET_CLEARS_NS); > + } > + > + return call.status; > +} > + > +static efi_status_t xen_efi_set_time(efi_time_t *tm) > +{ > + DECLARE_CALL(set_time); > + > + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time)); > + memcpy(&call.u.set_time, tm, sizeof(*tm)); > + > + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; > +} > + > +static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, > + efi_bool_t *pending, > + efi_time_t *tm) > +{ > + int err; > + DECLARE_CALL(get_wakeup_time); > + > + err = HYPERVISOR_dom0_op(&op); > + if (err) > + return EFI_UNSUPPORTED; > + > + if (tm) { > + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time)); > + memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm)); > + } > + > + if (enabled) > + *enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED); > + > + if (pending) > + *pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING); > + > + return call.status; > +} > + > +static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, > efi_time_t *tm) > +{ > + DECLARE_CALL(set_wakeup_time); > + > + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time)); > + if (enabled) > + call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE; > + if (tm) > + memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm)); > + else > + call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY; > + > + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; > +} > + > +static efi_status_t xen_efi_get_variable(efi_char16_t *name, > + efi_guid_t *vendor, > + u32 *attr, > + unsigned long *data_size, > + void *data) > +{ > + int err; > + DECLARE_CALL(get_variable); > + > + set_xen_guest_handle(call.u.get_variable.name, name); > + BUILD_BUG_ON(sizeof(*vendor) !> + sizeof(call.u.get_variable.vendor_guid)); > + memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor)); > + call.u.get_variable.size = *data_size; > + set_xen_guest_handle(call.u.get_variable.data, data); > + err = HYPERVISOR_dom0_op(&op); > + if (err) > + return EFI_UNSUPPORTED; > + > + *data_size = call.u.get_variable.size; > + *attr = call.misc; /* misc in struction is U32 variable*/ > + > + return call.status; > +} > + > +static efi_status_t xen_efi_get_next_variable(unsigned long *name_size, > + efi_char16_t *name, > + efi_guid_t *vendor) > +{ > + int err; > + DECLARE_CALL(get_next_variable_name); > + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) > + return EFI_UNSUPPORTED; > + call.u.get_next_variable_name.size = *name_size; > + set_xen_guest_handle(call.u.get_next_variable_name.name, name); > + BUILD_BUG_ON(sizeof(*vendor) !> + sizeof(call.u.get_next_variable_name.vendor_guid)); > + memcpy(&call.u.get_next_variable_name.vendor_guid, vendor, > + sizeof(*vendor)); > + err = HYPERVISOR_dom0_op(&op); > + if (err) > + return EFI_UNSUPPORTED; > + > + *name_size = call.u.get_next_variable_name.size; > + memcpy(vendor, &call.u.get_next_variable_name.vendor_guid, > + sizeof(*vendor)); > + > + return call.status; > +} > + > +static efi_status_t xen_efi_set_variable(efi_char16_t *name, > + efi_guid_t *vendor, > + u32 attr, > + unsigned long data_size, > + void *data) > +{ > + DECLARE_CALL(set_variable); > + > + set_xen_guest_handle(call.u.set_variable.name, name); > + call.misc = attr; > + BUILD_BUG_ON(sizeof(*vendor) !> + sizeof(call.u.set_variable.vendor_guid)); > + memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor)); > + call.u.set_variable.size = data_size; > + set_xen_guest_handle(call.u.set_variable.data, data); > + > + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; > +} > + > +static efi_status_t xen_efi_query_variable_info(u32 attr, > + u64 *storage_space, > + u64 *remaining_space, > + u64 *max_variable_size) > +{ > + int err; > + DECLARE_CALL(query_variable_info); > + > + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) > + return EFI_UNSUPPORTED; > + > + err = HYPERVISOR_dom0_op(&op); > + if (err) > + return EFI_UNSUPPORTED; > + > + *storage_space = call.u.query_variable_info.max_store_size; > + *remaining_space = call.u.query_variable_info.remain_store_size; > + *max_variable_size = call.u.query_variable_info.max_size; > + > + return call.status; > +} > + > +static efi_status_t xen_efi_get_next_high_mono_count(u32 *count) > +{ > + int err; > + DECLARE_CALL(get_next_high_monotonic_count); > + > + err = HYPERVISOR_dom0_op(&op); > + if (err) > + return EFI_UNSUPPORTED; > + > + *count = call.misc; > + > + return call.status; > +} > + > +static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules, > + unsigned long count, > + unsigned long sg_list) > +{ > + DECLARE_CALL(update_capsule); > + > + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) > + return EFI_UNSUPPORTED; > + > + set_xen_guest_handle(call.u.update_capsule.capsule_header_array, > + capsules); > + call.u.update_capsule.capsule_count = count; > + call.u.update_capsule.sg_list = sg_list; > + > + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; > +} > + > +static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t > **capsules, > + unsigned long count, > + u64 *max_size, > + int *reset_type) > +{ > + int err; > + DECLARE_CALL(query_capsule_capabilities); > + > + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) > + return EFI_UNSUPPORTED; > + > + set_xen_guest_handle(call.u.query_capsule_capabilities. > + capsule_header_array, capsules); > + call.u.query_capsule_capabilities.capsule_count = count; > + > + err = HYPERVISOR_dom0_op(&op); > + if (err) > + return EFI_UNSUPPORTED; > + > + *max_size = call.u.query_capsule_capabilities.max_capsule_size; > + *reset_type = call.u.query_capsule_capabilities.reset_type; > + > + return call.status; > +} > + > +#undef DECLARE_CALL > +#undef call > + > +static void xen_efi_reset_system(int reset_type, > + efi_status_t status, > + unsigned long data_size, > + efi_char16_t *data) > +{ > + struct sched_shutdown r = { .reason = SHUTDOWN_reboot }; > + > + if (HYPERVISOR_sched_op(SCHEDOP_shutdown, &r)) > + BUG(); > +} > + > +void __init xen_efi_probe(void) > +{ > + static struct xen_platform_op __initdata op = { > + .cmd = XENPF_firmware_info, > + .u.firmware_info = { > + .type = XEN_FW_EFI_INFO, > + .index = XEN_FW_EFI_CONFIG_TABLE > + } > + }; > + > + if (HYPERVISOR_dom0_op(&op) == 0) { > + /* TODO: check return info */ > + set_bit(EFI_XEN, &x86_efi_facility); > + set_bit(EFI_BOOT, &x86_efi_facility); > + /* since hypervisor calls the runtime, 32/64 bit > + * EFI/kernel mismatch is not an issue. Set to > + * match kernel so runtime calls will be made */ > +#ifdef CONFIG_64BIT > + set_bit(EFI_64BIT, &x86_efi_facility); > +#endif > + } > +} > + > + > +void __init efi_init_xen(void) > +{ > + efi_char16_t c16[100]; > + char vendor[ARRAY_SIZE(c16)] = "unknown"; > + int ret, i; > + struct xen_platform_op op; > + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; > + > + /* redirect system to Xen hypercall implementation */ > + efi.systab = NULL, > + efi.mps = EFI_INVALID_TABLE_ADDR; > + efi.acpi = EFI_INVALID_TABLE_ADDR; > + efi.acpi20 = EFI_INVALID_TABLE_ADDR; > + efi.smbios = EFI_INVALID_TABLE_ADDR; > + efi.sal_systab = EFI_INVALID_TABLE_ADDR; > + efi.boot_info = EFI_INVALID_TABLE_ADDR; > + efi.hcdp = EFI_INVALID_TABLE_ADDR; > + efi.uga = EFI_INVALID_TABLE_ADDR; > + efi.uv_systab = EFI_INVALID_TABLE_ADDR; > + efi.get_time = xen_efi_get_time; > + efi.set_time = xen_efi_set_time; > + efi.get_wakeup_time = xen_efi_get_wakeup_time; > + efi.set_wakeup_time = xen_efi_set_wakeup_time; > + efi.get_variable = xen_efi_get_variable; > + efi.get_next_variable = xen_efi_get_next_variable; > + efi.set_variable = xen_efi_set_variable; > + efi.query_variable_info = xen_efi_query_variable_info; > + efi.update_capsule = xen_efi_update_capsule; > + efi.query_capsule_caps = xen_efi_query_capsule_caps; > + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; > + efi.set_virtual_address_map = NULL; > + efi.reset_system = xen_efi_reset_system; > + > + /* > + * Show what we know for posterity > + */ > + op.cmd = XENPF_firmware_info; > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > + > + op.u.firmware_info.index = XEN_FW_EFI_VENDOR; > + info->vendor.bufsz = sizeof(c16); > + set_xen_guest_handle(info->vendor.name, c16); > + ret = HYPERVISOR_dom0_op(&op); > + if (!ret) { > + for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i) > + vendor[i] = c16[i]; > + vendor[i] = ''\0''; > + } else > + pr_err("Could not get the firmware vendor!\n"); > + > + op.u.firmware_info.index = XEN_FW_EFI_VERSION; > + ret = HYPERVISOR_dom0_op(&op); > + if (!ret) > + pr_info("EFI-xen v%u.%.02u by %s\n", > + info->version >> 16, > + info->version & 0xffff, vendor); > + else > + pr_err("Could not get EFI revision!\n"); > + > + op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION; > + ret = HYPERVISOR_dom0_op(&op); > + if (!ret) > + efi.runtime_version = info->version; > + else > + pr_warn(PFX "Could not get runtime services revision.\n"); > + set_bit(EFI_RUNTIME_SERVICES, &x86_efi_facility); > + > + /* > + * Let''s see what config tables the firmware passed to us. > + */ > + op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE; > + if (HYPERVISOR_dom0_op(&op)) > + BUG(); > + > + if (efi_config_init(info->cfg.addr, info->cfg.nent, > + sizeof(efi_config_table_64_t))) > + panic("Could not init EFI Configuration Tables!\n"); > + set_bit(EFI_CONFIG_TABLES, &x86_efi_facility); > + > + /* the EFI memory info is digested by the hypervisor and > + * supplied to dom0 via E820 entries */ > + set_bit(EFI_MEMMAP, &x86_efi_facility); > + > + set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility); /* not checked */ > + > + /* NOTE: efi.c only does this for CONFIG_X86_32 */ > + x86_platform.get_wallclock = efi_get_time; > + x86_platform.set_wallclock = efi_set_rtc_mmss; > +} > + > +/* > + * Convenience functions to obtain memory types and attributes > + */ > +u32 efi_mem_type_xen(unsigned long phys_addr) > +{ > + struct xen_platform_op op; > + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; > + > + op.cmd = XENPF_firmware_info; > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > + op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO; > + info->mem.addr = phys_addr; > + info->mem.size = 0; > + return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type; > +} > + > +u64 efi_mem_attributes_xen(unsigned long phys_addr) > +{ > + struct xen_platform_op op; > + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; > + > + op.cmd = XENPF_firmware_info; > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > + op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO; > + info->mem.addr = phys_addr; > + info->mem.size = 0; > + return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr; > +} > + > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index 193097e..51edc64 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -32,6 +32,7 @@ > #include <linux/gfp.h> > #include <linux/memblock.h> > #include <linux/edd.h> > +#include <linux/efi.h> > > #include <xen/xen.h> > #include <xen/events.h> > @@ -1342,15 +1343,6 @@ int xen_panic_handler_init(void) > return 0; > } > > -static const struct machine_ops xen_machine_ops __initconst = { > - .restart = xen_restart, > - .halt = xen_machine_halt, > - .power_off = xen_machine_power_off, > - .shutdown = xen_machine_halt, > - .crash_shutdown = xen_crash_shutdown, > - .emergency_restart = xen_emergency_restart, > -}; > - > static void __init xen_boot_params_init_edd(void) > { > #if IS_ENABLED(CONFIG_EDD) > @@ -1493,7 +1485,12 @@ asmlinkage void __init xen_start_kernel(void) > pv_mmu_ops.ptep_modify_prot_commit = xen_ptep_modify_prot_commit; > } > > - machine_ops = xen_machine_ops; > + machine_ops.restart = xen_restart; > + machine_ops.halt = xen_machine_halt; > + machine_ops.power_off = xen_machine_power_off; > + machine_ops.shutdown = xen_machine_halt; > + machine_ops.crash_shutdown = xen_crash_shutdown; > + machine_ops.emergency_restart = xen_emergency_restart; > > /* > * The only reliable way to retain the initial address of the > @@ -1613,6 +1610,11 @@ asmlinkage void __init xen_start_kernel(void) > > xen_setup_runstate_info(0); > > +#ifdef CONFIG_EFI > + if (xen_initial_domain()) > + xen_efi_probe(); > +#endif > + > /* Start the world */ > #ifdef CONFIG_X86_32 > i386_start_kernel(); > diff --git a/include/linux/efi.h b/include/linux/efi.h > index 5f8f176..2781dea 100644 > --- a/include/linux/efi.h > +++ b/include/linux/efi.h > @@ -84,7 +84,10 @@ typedef struct { > #define EFI_PAL_CODE 13 > #define EFI_MAX_MEMORY_TYPE 14 > > +#define EFI_INVALID_TYPE 0xffffffff > + > /* Attribute values: */ > +#define EFI_INVALID_ATTRIBUTE ((u64)0x0000000000000000ULL) /* > invalid attribute */ > #define EFI_MEMORY_UC ((u64)0x0000000000000001ULL) /* uncached */ > #define EFI_MEMORY_WC ((u64)0x0000000000000002ULL) /* write-coalescing */ > #define EFI_MEMORY_WT ((u64)0x0000000000000004ULL) /* write-through */ > @@ -597,6 +600,10 @@ extern void > efi_initialize_iomem_resources(struct resource *code_resource, > extern void efi_get_time(struct timespec *now); > extern int efi_set_rtc_mmss(const struct timespec *now); > extern void efi_reserve_boot_services(void); > +#ifdef CONFIG_XEN > +extern int __init efi_config_init(u64 tables, int nr_tables, int entrySz); > +extern void xen_efi_probe(void); > +#endif > extern struct efi_memory_map memmap; > > /** > @@ -634,6 +641,7 @@ extern int __init efi_setup_pcdp_console(char *); > #define EFI_RUNTIME_SERVICES 3 /* Can we use runtime services? */ > #define EFI_MEMMAP 4 /* Can we use EFI memory map? */ > #define EFI_64BIT 5 /* Is the firmware 64-bit? */ > +#define EFI_XEN 6 /* Must we access EFI via Xen? */ > > #ifdef CONFIG_EFI > # ifdef CONFIG_X86 > diff --git a/include/xen/interface/platform.h > b/include/xen/interface/platform.h > index c57d5f6..d005f0b 100644 > --- a/include/xen/interface/platform.h > +++ b/include/xen/interface/platform.h > @@ -108,10 +108,111 @@ struct xenpf_platform_quirk { > }; > DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); > > +#define XENPF_efi_runtime_call 49 > +#define XEN_EFI_get_time 1 > +#define XEN_EFI_set_time 2 > +#define XEN_EFI_get_wakeup_time 3 > +#define XEN_EFI_set_wakeup_time 4 > +#define XEN_EFI_get_next_high_monotonic_count 5 > +#define XEN_EFI_get_variable 6 > +#define XEN_EFI_set_variable 7 > +#define XEN_EFI_get_next_variable_name 8 > +#define XEN_EFI_query_variable_info 9 > +#define XEN_EFI_query_capsule_capabilities 10 > +#define XEN_EFI_update_capsule 11 > + > +struct xenpf_efi_runtime_call { > + uint32_t function; > + /* > + * This field is generally used for per sub-function flags (defined > + * below), except for the XEN_EFI_get_next_high_monotonic_count case, > + * where it holds the single returned value. > + */ > + uint32_t misc; > + unsigned long status; > + union { > +#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001 > + struct { > + struct xenpf_efi_time { > + uint16_t year; > + uint8_t month; > + uint8_t day; > + uint8_t hour; > + uint8_t min; > + uint8_t sec; > + uint32_t ns; > + int16_t tz; > + uint8_t daylight; > + } time; > + uint32_t resolution; > + uint32_t accuracy; > + } get_time; > + > + struct xenpf_efi_time set_time; > + > +#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001 > +#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002 > + struct xenpf_efi_time get_wakeup_time; > + > +#define XEN_EFI_SET_WAKEUP_TIME_ENABLE 0x00000001 > +#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002 > + struct xenpf_efi_time set_wakeup_time; > + > +#define XEN_EFI_VARIABLE_NON_VOLATILE 0x00000001 > +#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002 > +#define XEN_EFI_VARIABLE_RUNTIME_ACCESS 0x00000004 > + struct { > + GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ > + unsigned long size; > + GUEST_HANDLE(void) data; > + struct xenpf_efi_guid { > + uint32_t data1; > + uint16_t data2; > + uint16_t data3; > + uint8_t data4[8]; > + } vendor_guid; > + } get_variable, set_variable; > + > + struct { > + unsigned long size; > + GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ > + struct xenpf_efi_guid vendor_guid; > + } get_next_variable_name; > + > + struct { > + uint32_t attr; > + uint64_t max_store_size; > + uint64_t remain_store_size; > + uint64_t max_size; > + } query_variable_info; > + > + struct { > + GUEST_HANDLE(void) capsule_header_array; > + unsigned long capsule_count; > + uint64_t max_capsule_size; > + unsigned int reset_type; > + } query_capsule_capabilities; > + > + struct { > + GUEST_HANDLE(void) capsule_header_array; > + unsigned long capsule_count; > + uint64_t sg_list; /* machine address */ > + } update_capsule; > + } u; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call); > + > #define XENPF_firmware_info 50 > #define XEN_FW_DISK_INFO 1 /* from int 13 AH=08/41/48 */ > #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ > #define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=4f15 */ > +#define XEN_FW_EFI_INFO 4 /* from EFI */ > +#define XEN_FW_EFI_VERSION 0 > +#define XEN_FW_EFI_CONFIG_TABLE 1 > +#define XEN_FW_EFI_VENDOR 2 > +#define XEN_FW_EFI_MEM_INFO 3 > +#define XEN_FW_EFI_RT_VERSION 4 > +#define XEN_FW_EFI_PCI_ROM 5 > #define XEN_FW_KBD_SHIFT_FLAGS 5 /* Int16, Fn02: Get keyboard > shift flags. */ > struct xenpf_firmware_info { > /* IN variables. */ > @@ -143,6 +244,36 @@ struct xenpf_firmware_info { > /* must refer to 128-byte buffer */ > GUEST_HANDLE(uchar) edid; > } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ > + union xenpf_efi_info { > + uint32_t version; > + struct { > + uint64_t addr; /* EFI_CONFIGURATION_TABLE */ > + uint32_t nent; > + } cfg; > + struct { > + uint32_t revision; > + uint32_t bufsz; /* input, in bytes */ > + GUEST_HANDLE(void) name; > + /* UCS-2/UTF-16 string */ > + } vendor; > + struct { > + uint64_t addr; > + uint64_t size; > + uint64_t attr; > + uint32_t type; > + } mem; > + struct { > + /* IN variables */ > + uint16_t segment; > + uint8_t bus; > + uint8_t devfn; > + uint16_t vendor; > + uint16_t devid; > + /* OUT variables */ > + uint64_t address; > + xen_ulong_t size; > + } pci_rom; > + } efi_info; /* XEN_FW_EFI_INFO */ > > uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */ > } u; > @@ -361,6 +492,7 @@ struct xen_platform_op { > struct xenpf_read_memtype read_memtype; > struct xenpf_microcode_update microcode; > struct xenpf_platform_quirk platform_quirk; > + struct xenpf_efi_runtime_call efi_runtime_call; > struct xenpf_firmware_info firmware_info; > struct xenpf_enter_acpi_sleep enter_acpi_sleep; > struct xenpf_change_freq change_freq; > -- > 1.8.3.4 >
Eric Shelton
2013-Aug-15 20:24 UTC
Re: Is: Linux-EFI code to call Xen''s EFI hypercalls [RFC PATCH comments] Was:Re: Xen 4.4 development update
On Thu, Aug 15, 2013 at 10:12 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Thu, Aug 15, 2013 at 01:32:12AM -0400, Eric Shelton wrote: > > First of, thank you for taking a stab at it and redoing it.Sure. The first releases of the patch were posted during a hectic time in the release cycle. Three months later, I wanted to make sure this had not gotten lost in the noise, and instead got wrapped up while it was still fairly fresh for me.> Some general comments: > - the #ifdef CONFIG_XEN is generaly frowend upon. If you need them they should > be in header files. The exception is the CONFIG_X86 and > CONFIG_X86_64. Now said that there are other instances of code where > it is sprinkled with #ifdef CONFIG_ACPI .. #ifdef CONFIG_PCI, and so > on. It would have been nice if all of that got moved to a header file > but in reality that could make it just more confusing. Enough about > that - what I want to say is that doing #idef CONFIG_XEN is something > we have been trying the utmost to not put in generic code. The > reasoning is that instead of using the API (so for example if we have > an generic layer and then there are platform related drivers - we > want to implement the stuff in the platform drivers - not add > side-channels for a specific platform).OK. Hopefully the reorganization I suggest below will clear out most or all of this.> - Is there any way to move the bulk of the hypercalls in the > efi_runtime services. Meaning alter the efi_runtime services > to do hypercalls instead of EFI calls? That way I would think most > of the EFI general logic would be untouched? This is going back to > the first comment - you would want to leave as much generic code > untouched as possible. And implement the bulk of the code in the > platform specific code.This sounds similar to Matthew Garrett''s suggestion "to do this by replacing efi_call_* I''m not quite sure how I would "alter the efi_runtime services" to accomplish this - or at least not in some way that is not worse than what is being done for things like *_set_variable(). If you can more concretely show me how this might be coded for one of the runtime service functions, I would be happy to replicate that across the patch. Rather than doing that,I would suggest, as least as far as the runtime services are concerned, that the architecture/implementation specific code has been narrowly encapsulated - in the virt_efi_* functions in efi.c, and in the corresponding xen_efi_* functions in xen.c. These are registered in the function table included in the ''efi'' struct and called through there, and are essentially setter/getter functions without any general logic. There are higher level functions, such as efi_set_rtc_mmss(), and they use the function table to get/set EFI info as needed, and have not been duplicated. The runtime services look pretty cleanly implemented in this way, and introduce essentially no changes since this general mechanism was already in place. The only improvement I might suggest is to break out the runtime services function pointers into a separate struct, perhaps named efi_runtime, as it would make it a bit clearer they are runtime services accessor methods. The remaining functions are for initialization, and these are where the "if efi_enabled(EFI_XEN)" and "#ifdef CONFIG_XEN" stuff crept in. Many of the differences arise from the fact that much of what the kernel originally did for EFI init has been moved into the hypervisor, and the information is accessed via hypercalls. As a result, xen.c has much less to do than efi.c, which has to concern itself with memory mapping of the system and runtime services tables. Where dom0 is booting under Xen, various init functions were changed to return immediately, as this extra work does not need to be done. It sounds like I should return to what the original patches were doing, and make use of a function table for the init functions, much as done for the runtime services. However, as function pointers were not in the original code, this looked a bit uglier in the first patches, because each original efi_*_init function ended up with a counterpart efi_*_init_generic function, which did "if (func_ptr =NULL) { return; } else { func_ptr(args); }", with most values being NULL in xen.c (probably because many table entries were only called internally in efi.c). I can make this a little less ugly by (1) minimizing the functions in the table, and (2) making table.func_ptr() calls instead of *_generic() calls. Additionally it might be sensible to split up efi.c into efi_runtime.c and efi_init.c to separately bundle the functions used during these two phases of operation. The maintainer for the linux kernel would have to rule on that idea...> - When approaching Matthew I would suggest you label it as RFC - to get > an idea of how he would like it done - as I don''t think he will > take the patch as is. He might suggest the thing I just mentioned > above. Or perhaps make most of the ''efi_*'' calls go through some form > of function table that by default is set to baremetal_efi_calls > (see x86_init.c)See above. This appears to already be happening for the runtime services calls. The problems appear to be with init code, which I will try to resolve with a similar function table-based approach.> - There are some code paths that just do: > if (xen) > return; > But it is not clear why that is so (missing comments). This is needed > b/c if somebody wants to redo the code in the future they would need to > know where to place that ''if (xen) do something different''The course laid out above will remove this code, in favor of the additional function table.> - You want to credit Jan Beulich in the commit description saying > that the patch was derieved from the work that he did for SuSE Linux. > Liang Tang took some of that - but he forgot to mention that in the > initial post.Definitely. If the hypercalls and original patches had not been around, I likely would not have gone very far with this, and instead stuck with the weird legacy BIOS boot mechanisms provided by Apple (mainly for Bootcamp).> - It is unclear to me why the machine_ops assigment has been changed?Sorry, that was a result of work with a C++ codebase that generally disfavored object-to-object assignments. The original struct-to-struct assignment was legitimate, and will be restored.> Thank you again for taking a stab at it! I know that getting push back > on patches is not a thing that anybody likes - but the end goal is make > it be fantastic and sometimes that takes a couple of rounds (or about a > dozen as my first patches for Linux took that many revisions)No problem on the comments. This is mainly about a cleaner and clearer presentation on the code. I appreciate having an express indication of the coding philosophies and design patterns for both Xen and the Linux kernel, especially if it smooths the path through LKML. - Eric
Konrad Rzeszutek Wilk
2013-Aug-15 20:50 UTC
Re: Is: Linux-EFI code to call Xen''s EFI hypercalls [RFC PATCH comments] Was:Re: Xen 4.4 development update
On Thu, Aug 15, 2013 at 04:24:20PM -0400, Eric Shelton wrote:> On Thu, Aug 15, 2013 at 10:12 AM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > On Thu, Aug 15, 2013 at 01:32:12AM -0400, Eric Shelton wrote: > > > > First of, thank you for taking a stab at it and redoing it. > > Sure. The first releases of the patch were posted during a hectic > time in the release cycle. Three months later, I wanted to make sure > this had not gotten lost in the noise, and instead got wrapped up > while it was still fairly fresh for me. > > > Some general comments: > > - the #ifdef CONFIG_XEN is generaly frowend upon. If you need them they should > > be in header files. The exception is the CONFIG_X86 and > > CONFIG_X86_64. Now said that there are other instances of code where > > it is sprinkled with #ifdef CONFIG_ACPI .. #ifdef CONFIG_PCI, and so > > on. It would have been nice if all of that got moved to a header file > > but in reality that could make it just more confusing. Enough about > > that - what I want to say is that doing #idef CONFIG_XEN is something > > we have been trying the utmost to not put in generic code. The > > reasoning is that instead of using the API (so for example if we have > > an generic layer and then there are platform related drivers - we > > want to implement the stuff in the platform drivers - not add > > side-channels for a specific platform). > > OK. Hopefully the reorganization I suggest below will clear out most > or all of this. > > > - Is there any way to move the bulk of the hypercalls in the > > efi_runtime services. Meaning alter the efi_runtime services > > to do hypercalls instead of EFI calls? That way I would think most > > of the EFI general logic would be untouched? This is going back to > > the first comment - you would want to leave as much generic code > > untouched as possible. And implement the bulk of the code in the > > platform specific code. > > This sounds similar to Matthew Garrett''s suggestion "to do this by > replacing efi_call_* I''m not quite sure how I would "alter the > efi_runtime services" to accomplish this - or at least not in some way > that is not worse than what is being done for things like > *_set_variable(). If you can more concretely show me how this might > be coded for one of the runtime service functions, I would be happy to > replicate that across the patch.Ha! I am just hand-waving right now :-) What I had in mind was that this: efi_phys.systab = (efi_system_table_t *)boot_params.efi_info.efi_systab; Is done, and we could implement some stub functions in the efi_systab that would convert the Microsoft stack passing to normal Linux and then do the hypercalls. It would be a bit of this: virt_efi_get_time -> calls efi_call_virt2 (efi_stub_32|64.S) -> assembler code Linux to EFI stacks, and calls in efi.systab->runtime->get_time The get_time would be our own little blob of code that alters the parameters from EFI stack to Linux and makes the hypercall (so probably in C). Then when the hypercall is done, it changes the stack back to EFI and returns. In other words we would implement an EFI runtime code that actually would do hypercalls. But from your analysis that does not solve the whole problem. Those efi_init* variants in some cases are unneccessary. Which brings another question - if we do barell throught them, what is the worst that will happen? Can the values returned be the same?> > Rather than doing that,I would suggest, as least as far as the runtime > services are concerned, that the architecture/implementation specific > code has been narrowly encapsulated - in the virt_efi_* functions in > efi.c, and in the corresponding xen_efi_* functions in xen.c. These > are registered in the function table included in the ''efi'' struct and > called through there, and are essentially setter/getter functions > without any general logic. There are higher level functions, such as > efi_set_rtc_mmss(), and they use the function table to get/set EFI > info as needed, and have not been duplicated. The runtime services > look pretty cleanly implemented in this way, and introduce essentially > no changes since this general mechanism was already in place. The > only improvement I might suggest is to break out the runtime services > function pointers into a separate struct, perhaps named efi_runtime, > as it would make it a bit clearer they are runtime services accessor > methods.Ok, so you are hoisting this a bit higher. That would work too - and it would be less messier. I think getting Matthew''s thoughts on this is neccessary - as at the end of this it is his call.> > The remaining functions are for initialization, and these are where > the "if efi_enabled(EFI_XEN)" and "#ifdef CONFIG_XEN" stuff crept in. > Many of the differences arise from the fact that much of what the > kernel originally did for EFI init has been moved into the hypervisor, > and the information is accessed via hypercalls. As a result, xen.c > has much less to do than efi.c, which has to concern itself with > memory mapping of the system and runtime services tables. Where dom0 > is booting under Xen, various init functions were changed to return > immediately, as this extra work does not need to be done.If we prepapred the efi structures (hand-waving here) with the data that the hypervisor has already setup and give that to this code - would that work? Basically it would (I hope) just walk throught the same steps that the hypervisor did, but all of this efi calls would be stubbed out. For example the E820 - we already do some of that in setup.c so I would think this could just prepare an memmap that has no entries. Or get the entries from the XENMEM_machine_memory_map like in arch/x86/xen/setup.c and just prepare the memmap.. Thought there is a bunch of goodness happening in xen_memory_setup() that should still be invoked.> > It sounds like I should return to what the original patches were > doing, and make use of a function table for the init functions, much > as done for the runtime services. However, as function pointers wereThe original ones were much larger and the maintainer (Matthew) was not too thrilled about them.> not in the original code, this looked a bit uglier in the first > patches, because each original efi_*_init function ended up with a > counterpart efi_*_init_generic function, which did "if (func_ptr => NULL) { return; } else { func_ptr(args); }", with most values being > NULL in xen.c (probably because many table entries were only called > internally in efi.c). I can make this a little less ugly by (1) > minimizing the functions in the table, and (2) making table.func_ptr() > calls instead of *_generic() calls. > > Additionally it might be sensible to split up efi.c into efi_runtime.c > and efi_init.c to separately bundle the functions used during these > two phases of operation. The maintainer for the linux kernel would > have to rule on that idea...Yeah, it comes back to how Matthew would like it. And I need to do some more homework and look more dilligiently at the efi.c code. Next week should be able to do that.> > > - When approaching Matthew I would suggest you label it as RFC - to get > > an idea of how he would like it done - as I don''t think he will > > take the patch as is. He might suggest the thing I just mentioned > > above. Or perhaps make most of the ''efi_*'' calls go through some form > > of function table that by default is set to baremetal_efi_calls > > (see x86_init.c) > > See above. This appears to already be happening for the runtime > services calls. The problems appear to be with init code, which I > will try to resolve with a similar function table-based approach. > > > - There are some code paths that just do: > > if (xen) > > return; > > But it is not clear why that is so (missing comments). This is needed > > b/c if somebody wants to redo the code in the future they would need to > > know where to place that ''if (xen) do something different'' > > The course laid out above will remove this code, in favor of the > additional function table. > > > - You want to credit Jan Beulich in the commit description saying > > that the patch was derieved from the work that he did for SuSE Linux. > > Liang Tang took some of that - but he forgot to mention that in the > > initial post. > > Definitely. If the hypercalls and original patches had not been > around, I likely would not have gone very far with this, and instead > stuck with the weird legacy BIOS boot mechanisms provided by Apple > (mainly for Bootcamp). > > > - It is unclear to me why the machine_ops assigment has been changed? > > Sorry, that was a result of work with a C++ codebase that generally > disfavored object-to-object assignments. The original > struct-to-struct assignment was legitimate, and will be restored. > > > Thank you again for taking a stab at it! I know that getting push back > > on patches is not a thing that anybody likes - but the end goal is make > > it be fantastic and sometimes that takes a couple of rounds (or about a > > dozen as my first patches for Linux took that many revisions) > > No problem on the comments. This is mainly about a cleaner and > clearer presentation on the code. I appreciate having an express > indication of the coding philosophies and design patterns for both Xen > and the Linux kernel, especially if it smooths the path through LKML.Yeeey!> > - Eric
Konrad Rzeszutek Wilk
2013-Aug-16 14:10 UTC
Re: Is: Linux-EFI code to call Xen''s EFI hypercalls [RFC PATCH comments] Was:Re: Xen 4.4 development update
On Thu, Aug 15, 2013 at 04:50:47PM -0400, Konrad Rzeszutek Wilk wrote:> On Thu, Aug 15, 2013 at 04:24:20PM -0400, Eric Shelton wrote: > > On Thu, Aug 15, 2013 at 10:12 AM, Konrad Rzeszutek Wilk > > <konrad.wilk@oracle.com> wrote: > > > On Thu, Aug 15, 2013 at 01:32:12AM -0400, Eric Shelton wrote: > > > > > > First of, thank you for taking a stab at it and redoing it. > > > > Sure. The first releases of the patch were posted during a hectic > > time in the release cycle. Three months later, I wanted to make sure > > this had not gotten lost in the noise, and instead got wrapped up > > while it was still fairly fresh for me. > > > > > Some general comments: > > > - the #ifdef CONFIG_XEN is generaly frowend upon. If you need them they should > > > be in header files. The exception is the CONFIG_X86 and > > > CONFIG_X86_64. Now said that there are other instances of code where > > > it is sprinkled with #ifdef CONFIG_ACPI .. #ifdef CONFIG_PCI, and so > > > on. It would have been nice if all of that got moved to a header file > > > but in reality that could make it just more confusing. Enough about > > > that - what I want to say is that doing #idef CONFIG_XEN is something > > > we have been trying the utmost to not put in generic code. The > > > reasoning is that instead of using the API (so for example if we have > > > an generic layer and then there are platform related drivers - we > > > want to implement the stuff in the platform drivers - not add > > > side-channels for a specific platform). > > > > OK. Hopefully the reorganization I suggest below will clear out most > > or all of this. > > > > > - Is there any way to move the bulk of the hypercalls in the > > > efi_runtime services. Meaning alter the efi_runtime services > > > to do hypercalls instead of EFI calls? That way I would think most > > > of the EFI general logic would be untouched? This is going back to > > > the first comment - you would want to leave as much generic code > > > untouched as possible. And implement the bulk of the code in the > > > platform specific code. > > > > This sounds similar to Matthew Garrett''s suggestion "to do this by > > replacing efi_call_* I''m not quite sure how I would "alter the > > efi_runtime services" to accomplish this - or at least not in some way > > that is not worse than what is being done for things like > > *_set_variable(). If you can more concretely show me how this might > > be coded for one of the runtime service functions, I would be happy to > > replicate that across the patch. > > Ha! I am just hand-waving right now :-) > > What I had in mind was that this: > > efi_phys.systab = (efi_system_table_t *)boot_params.efi_info.efi_systab; > > Is done, and we could implement some stub functions in the efi_systab > that would convert the Microsoft stack passing to normal Linux > and then do the hypercalls. > > It would be a bit of this: > > virt_efi_get_time -> calls efi_call_virt2 (efi_stub_32|64.S) -> > assembler code Linux to EFI stacks, and calls in > efi.systab->runtime->get_time > > The get_time would be our own little blob of code that alters the > parameters from EFI stack to Linux and makes the hypercall (so probably > in C). Then when the hypercall is done, it changes the stack back to EFI > and returns. > > In other words we would implement an EFI runtime code that actually > would do hypercalls. > > But from your analysis that does not solve the whole problem. Those > efi_init* variants in some cases are unneccessary. Which brings another > question - if we do barell throught them, what is the worst that will > happen? Can the values returned be the same?Right after I sent the email I thought about another option. Which is the one I think Matthew was referring to. That is make efi_call* function be more of a function pointer and the default one (compiled) is the baremetal version. When Xen boots it over-writes it with its specific. There is also some lookup to figure out which of the set_time, get_time, etc calls are being called. This is all hand-waving and the patch below has not even been compile tested. From 197339fe9e4c95abe5b8948cf2bc3119c0ec87b5 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 16 Aug 2013 10:06:52 -0400 Subject: [PATCH] efi/xen: Use a function pointer for baremetal and Xen specific efi calls. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/include/asm/efi.h | 43 +++++++++++++++++++++++++++++++------ arch/x86/platform/efi/efi_64.c | 11 ++++++++++ arch/x86/platform/efi/efi_stub_64.S | 28 ++++++++++++------------ arch/x86/xen/efi.c | 40 ++++++++++++++++++++++++++++++++++ arch/x86/xen/setup.c | 9 ++++++++ arch/x86/xen/xen-ops.h | 13 +++++++++++ 6 files changed, 123 insertions(+), 21 deletions(-) create mode 100644 arch/x86/xen/efi.c diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index 0062a01..f234570 100644 --- a/arch/x86/include/asm/efi.h +++ b/arch/x86/include/asm/efi.h @@ -41,16 +41,45 @@ extern unsigned long asmlinkage efi_call_phys(void *, ...); #define EFI_LOADER_SIGNATURE "EL64" -extern u64 efi_call0(void *fp); -extern u64 efi_call1(void *fp, u64 arg1); -extern u64 efi_call2(void *fp, u64 arg1, u64 arg2); -extern u64 efi_call3(void *fp, u64 arg1, u64 arg2, u64 arg3); -extern u64 efi_call4(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4); -extern u64 efi_call5(void *fp, u64 arg1, u64 arg2, u64 arg3, +extern u64 native_efi_call0(void *fp); +extern u64 native_efi_call1(void *fp, u64 arg1); +extern u64 native_efi_call2(void *fp, u64 arg1, u64 arg2); +extern u64 native_efi_call3(void *fp, u64 arg1, u64 arg2, u64 arg3); +extern u64 native_efi_call4(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4); +extern u64 native_efi_call5(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5); -extern u64 efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3, +extern u64 native_efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5, u64 arg6); +#ifdef CONFIG_PARAVIRT +extern u64 (*platform_efi_call0)(void *fp); +extern u64 (*platform_efi_call1)(void *fp, u64 arg1); +extern u64 (*platform_efi_call2)(void *fp, u64 arg1, u64 arg2); +extern u64 (*platform_efi_call3)(void *fp, u64 arg1, u64 arg2, u64 arg3); +extern u64 (*platform_efi_call4)(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4); +extern u64 (*platform_efi_call5)(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5); +extern u64 (*platform_efi_call6)(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5, u64 arg6); + +#define efi_call0(f) platform_efi_call0(f) +#define efi_call1(f, a1) platform_efi_call1(f, a1) +#define efi_call2(f, a1, a2) platform_efi_call2(f, a1, a2) +#define efi_call3(f, a1, a2, a3) platform_efi_call3(f, a1, a2, a3) +#define efi_call4(f, a1, a2, a3, a4) platform_efi_call4(f, a1, a2, a3, a4) +#define efi_call5(f, a1, a2, a3, a4, a5) platform_efi_call5(f, a1, a2, a3, a4, a5) +#define efi_call6(f, a1, a2, a3, a4, a5, a6) platform_efi_call6(f, a1, a2, a3, a4, a5, a6) +#else +#define efi_call0(f) native_efi_call0(f) +#define efi_call1(f, a1) native_efi_call1(f, a1) +#define efi_call2(f, a1, a2) native_efi_call2(f, a1, a2) +#define efi_call3(f, a1, a2, a3) native_efi_call3(f, a1, a2, a3) +#define efi_call4(f, a1, a2, a3, a4) native_efi_call4(f, a1, a2, a3, a4) +#define efi_call5(f, a1, a2, a3, a4, a5) native_efi_call5(f, a1, a2, a3, a4, a5) +#define efi_call6(f, a1, a2, a3, a4, a5, a6) native_efi_call6(f, a1, a2, a3, a4, a5, a6) + +#endif + #define efi_call_phys0(f) \ efi_call0((f)) #define efi_call_phys1(f, a1) \ diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c index 39a0e7f..afa4354 100644 --- a/arch/x86/platform/efi/efi_64.c +++ b/arch/x86/platform/efi/efi_64.c @@ -113,3 +113,14 @@ void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size, return (void __iomem *)__va(phys_addr); } +#ifdef CONFIG_PARAVIRT +u64 (*platform_efi_call0)(void *fp) = native_efi_call0; +u64 (*platform_efi_call1)(void *fp, u64 arg1) = native_efi_call1; +u64 (*platform_efi_call2)(void *fp, u64 arg1, u64 arg2) = native_efi_call2; +u64 (*platform_efi_call3)(void *fp, u64 arg1, u64 arg2, u64 arg3) = native_efi_call3; +u64 (*platform_efi_call4)(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4) = native_efi_call4; +u64 (*platform_efi_call5)(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5) = native_efi_call5; +u64 (*platform_efi_call6)(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5, u64 arg6) = native_efi_call6; +#endif diff --git a/arch/x86/platform/efi/efi_stub_64.S b/arch/x86/platform/efi/efi_stub_64.S index 4c07cca..60e993c 100644 --- a/arch/x86/platform/efi/efi_stub_64.S +++ b/arch/x86/platform/efi/efi_stub_64.S @@ -34,16 +34,16 @@ mov %rsi, %cr0; \ mov (%rsp), %rsp -ENTRY(efi_call0) +ENTRY(native_efi_call0) SAVE_XMM subq $32, %rsp call *%rdi addq $32, %rsp RESTORE_XMM ret -ENDPROC(efi_call0) +ENDPROC(native_efi_call0) -ENTRY(efi_call1) +ENTRY(native_efi_call1) SAVE_XMM subq $32, %rsp mov %rsi, %rcx @@ -51,9 +51,9 @@ ENTRY(efi_call1) addq $32, %rsp RESTORE_XMM ret -ENDPROC(efi_call1) +ENDPROC(native_efi_call1) -ENTRY(efi_call2) +ENTRY(native_efi_call2) SAVE_XMM subq $32, %rsp mov %rsi, %rcx @@ -61,9 +61,9 @@ ENTRY(efi_call2) addq $32, %rsp RESTORE_XMM ret -ENDPROC(efi_call2) +ENDPROC(native_efi_call2) -ENTRY(efi_call3) +ENTRY(native_efi_call3) SAVE_XMM subq $32, %rsp mov %rcx, %r8 @@ -72,9 +72,9 @@ ENTRY(efi_call3) addq $32, %rsp RESTORE_XMM ret -ENDPROC(efi_call3) +ENDPROC(native_efi_call3) -ENTRY(efi_call4) +ENTRY(native_efi_call4) SAVE_XMM subq $32, %rsp mov %r8, %r9 @@ -84,9 +84,9 @@ ENTRY(efi_call4) addq $32, %rsp RESTORE_XMM ret -ENDPROC(efi_call4) +ENDPROC(native_efi_call4) -ENTRY(efi_call5) +ENTRY(native_efi_call5) SAVE_XMM subq $48, %rsp mov %r9, 32(%rsp) @@ -97,9 +97,9 @@ ENTRY(efi_call5) addq $48, %rsp RESTORE_XMM ret -ENDPROC(efi_call5) +ENDPROC(native_efi_call5) -ENTRY(efi_call6) +ENTRY(native_efi_call6) SAVE_XMM mov (%rsp), %rax mov 8(%rax), %rax @@ -113,4 +113,4 @@ ENTRY(efi_call6) addq $48, %rsp RESTORE_XMM ret -ENDPROC(efi_call6) +ENDPROC(native_efi_call6) diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c new file mode 100644 index 0000000..f09f829 --- /dev/null +++ b/arch/x86/xen/efi.c @@ -0,0 +1,40 @@ + +#include <asm/xen/hypercall.h> + +#include <xen/xen.h> +#include <linux/efi.h> +#include <asm/efi.h> +#include <xen/interface/physdev.h> +#include "xen-ops.h" + +efi_runtime_services_t xen_efi_fnc = { + .get_time = xen_get_time; + .set_time = xen_set_time; + /* and so on */ +}; +u64 xen_efi_call0(void *fp) +{ + char *func_idx; + u64 (*fnc)(void); + + /* + * Look up which of the functions it is in the platform + * code, and find the same function in the Xen platform. + */ + func_idx = &efi.systab->runtime - fp; + BUG_ON(func_idx == 0); /* Can''t be the header! */ + fnc = (char *)xen_efi_fnc + func_idx; /* This probably won''t compile. */ + + BUG_ON(!fnc); + fnc(); +} +/* and so on. +u64 xen_efi_call1(void *fp, u64 arg1); +u64 xen_efi_call2(void *fp, u64 arg1, u64 arg2); +u64 xen_efi_call3(void *fp, u64 arg1, u64 arg2, u64 arg3); +u64 xen_efi_call4(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4); +u64 xen_efi_call5(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5); +u64 xen_efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5, u64 arg6); +*/ diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 056d11f..cc820d2 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -563,4 +563,13 @@ void __init xen_arch_setup(void) #ifdef CONFIG_NUMA numa_off = 1; #endif +#ifdef CONFIG_EFI + platform_efi_call0 = xen_efi_call0; + platform_efi_call1 = xen_efi_call1; + platform_efi_call2 = xen_efi_call2; + platform_efi_call3 = xen_efi_call3; + platform_efi_call4 = xen_efi_call4; + platform_efi_call5 = xen_efi_call5; + platform_efi_call6 = xen_efi_call6; +#endif } diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index 86782c5..d680558 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -123,4 +123,17 @@ void xen_adjust_exception_frame(void); extern int xen_panic_handler_init(void); +#ifdef CONFIG_EFI +extern u64 xen_efi_call0(void *fp); +extern u64 xen_efi_call1(void *fp, u64 arg1); +extern u64 xen_efi_call2(void *fp, u64 arg1, u64 arg2); +extern u64 xen_efi_call3(void *fp, u64 arg1, u64 arg2, u64 arg3); +extern u64 xen_efi_call4(void *fp, u64 arg1, u64 arg2, u64 arg3, u64 arg4); +extern u64 xen_efi_call5(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5); +extern u64 xen_efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3, + u64 arg4, u64 arg5, u64 arg6); + + +#endif #endif /* XEN_OPS_H */ -- 1.7.11.7
On 15/08/13 14:24, Wei Liu wrote:> On Thu, Aug 15, 2013 at 02:08:01PM +0100, Jan Beulich wrote: >>>>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote: >>> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >>>> * Remove hardcoded mobprobe''s in xencommons >>>> owner: Wei Liu >>>> status: still in discussion >>>> >>> Have we not reached conclusion here? IIRC in a engineering meeting we >>> had you said we could just leave it as-is for now? >> ??? Didn''t we long ago agree that this hard coded loading is bogus >> and hence should go away? Remember this was originally planned >> to happen for 4.3, so any change in direction here needs a very >> good reason imo. >> > Actually I wasn''t completely sure I remembered the right thing. I might > be wrong about the conclusion. Geroge, do you have any clue? :-)I think the conclusion we came to was as follows: * Calling modprobe from libxl is not really feasible due to the fact that we have to call exec, which means making some of the calls async; one thing led to another and a huge number of calls would have had to be made async. * It is better if kernels use the auto-load mechanisms as much as possible, rather than modprobes either in the init scripts or from libxl * However, blktap is unmaintained. Unless someone steps up to add the functionality (which is not recommended as it would probably te a waste of effort), it will continue to require a modprobe. On newer systems, without blktap, the modprobe will be harmless. So for blktap, the modprobe will have to remain for the forseeable future. * It would be good if other modules were modified so that they were auto-loaded, rather than modprobed. However, this was outside of the scope of the work I or Wei agreed to do. We agreed to handle blktap, and the blktap module loading issue has been resolved. * Modifying other modules is an open ticket item Correct me if I''m wrong, anyone. I can put "auto-load other modules" on the roadmap without an owner, if you like. -George
On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote:> > * However, blktap is unmaintained. Unless someone steps up to add > the functionality (which is not recommended as it would probably te > a waste of effort), it will continue to require a modprobe. On newer > systems, without blktap, the modprobe will be harmless. So for > blktap, the modprobe will have to remain for the forseeable future. >What I''ve been wondering.. XenServer is shipping with and using blktap, so there must be someone maintaining blktap at Citrix? I also understand blktap is on the way out and will be replaced with qdisc in the future.. -- Pasi
On 19/08/13 13:08, Pasi Kärkkäinen wrote:> On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote: >> * However, blktap is unmaintained. Unless someone steps up to add >> the functionality (which is not recommended as it would probably te >> a waste of effort), it will continue to require a modprobe. On newer >> systems, without blktap, the modprobe will be harmless. So for >> blktap, the modprobe will have to remain for the forseeable future. >> > What I''ve been wondering.. XenServer is shipping with and using blktap, > so there must be someone maintaining blktap at Citrix? > I also understand blktap is on the way out and will be replaced with qdisc in the future..As I understand it, XenServer is using a private fork of blktap2, with significant changes. Since blktap2 as a whole can''t be upstreamed into the mainline kernel, I think the feeling was that there wasn''t any point in trying to upstream the local changes to the "classic" kernel. Blktap3 was meant to be the mainline-friendly version of blktap, but as you say, work on it has halted and the plan at the moment, I''m told is to look into qdisk, since it uses a similar technology, but gives access to work from other communities as well (Ceph, for example). Thanos, correct me if I''ve made a mistake somewhere... -George
> -----Original Message----- > From: George Dunlap [mailto:george.dunlap@eu.citrix.com] > Sent: 19 August 2013 13:54 > To: Pasi Kärkkäinen > Cc: Wei Liu; Ian Jackson; Jan Beulich; xen-devel@lists.xen.org; Thanos > Makatos > Subject: Re: [Xen-devel] Xen 4.4 development update > > On 19/08/13 13:08, Pasi Kärkkäinen wrote: > > On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote: > >> * However, blktap is unmaintained. Unless someone steps up to add > >> the functionality (which is not recommended as it would probably te > >> a waste of effort), it will continue to require a modprobe. On newer > >> systems, without blktap, the modprobe will be harmless. So for > >> blktap, the modprobe will have to remain for the forseeable future. > >> > > What I''ve been wondering.. XenServer is shipping with and using > blktap, > > so there must be someone maintaining blktap at Citrix? > > I also understand blktap is on the way out and will be replaced with > qdisc in the future.. > > As I understand it, XenServer is using a private fork of blktap2, with > significant changes. Since blktap2 as a whole can''t be upstreamed intoThat''s right, the so-called blktap2.5 that lives in github (https://github.com/xapi-project/blktap).> the mainline kernel, I think the feeling was that there wasn''t any > point > in trying to upstream the local changes to the "classic" kernel. > Blktap3 was meant to be the mainline-friendly version of blktap, but as > you say, work on it has halted and the plan at the moment, I''m told is > to look into qdisk, since it uses a similar technology, but gives > access > to work from other communities as well (Ceph, for example).blktap3 work hasn''t been halted, only the upstream process has. On the contrary, we''re still developing blktap3 (currently on https://github.com/tmakatos/blktap/tree/blktap3 but that''s temporary) and our plan is to have it working for XenServer rather soon. I don''t see any technical difficulties in Xen using blktap3, pretty much in the same way it does with qemu.> > Thanos, correct me if I''ve made a mistake somewhere... > > -George
On 14/08/13 17:35, Jan Beulich wrote:>>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >> 4.3 was released on 9 July. That would give us a release on 9 January >> 2014. This is fairly close after the Christmas season, so I propose >> to make the estimated release date later, on 21 January, giving a few >> extra weeks for the holiday season: >> >> * Feature freeze: 18 October 2013 >> * Code freezing point: 8 November 2013 >> * First RC: 26 November 2013 >> * Release: 21 January 2014 > So I didn''t see any comments on the proposed schedule so far. > Hence I wonder how fixed we have to consider that plan at > this point. I''m asking because from the very beginning I was > not really in favor of shortening the release cycle, and looking > at the number of (smaller) items on my todo list, I don''t see any > way to even get just a good part of them done by the proposed > feature freeze date (taking into consideration that working on > those items usually is possible only when no other bugs or > routine work need dealing with).I think as release cycles get shorter, we have to move into thinking more like the Linux "merge windows": you work on your feature, and when it''s ready, you target it for a specific merge window. Each release will have fewer features, but overall the work should continue at a similar pace. For 4.4, it seems likely that we will have stage one of PVH, host USB support, a Linux-based stubdom, a FreeBSD-based libc for minios, vNUMA for PV guests, possibly for HVM guests... that seems like a fairly feature-ful release. None of this is set in stone -- if we get to October and it looks like 4.4 is just "4.3 with some bug fixes", then we can just decide to extend the development cycle another few months. -George
On Mon, 2013-08-19 at 12:38 +0100, George Dunlap wrote:> I can put "auto-load other modules" on the roadmap without an owner, > if you like.I thought Waldi sent patches for most of hte other backends ages ago and this stuff just works these days. Yes, here we are: commit 149bb2fab547253e6359e76f1b86b95247110e68 Author: Bastian Blank <waldi@debian.org> Date: Wed Jun 29 14:40:08 2011 +0200 xen: Add module alias to autoload backend drivers All the Xen backend drivers are assigned to a special bus type xen-backend. This patch exports xen-backend:* names through modalias and uevent to autoload them. Signed-off-by: Bastian Blank <waldi@debian.org> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Seems to have been in 3.1-rc1. Maybe there are other driver which this didn''t affect, evtchn etc perhaps? I wonder if it is worth init time Xen code synthesising some uevents iff running on Xen to make these get loaded... Ian.
On Mon, 2013-08-19 at 14:09 +0100, George Dunlap wrote:> None of this is set in stone -- if we get to October and it looks like > 4.4 is just "4.3 with some bug fixes", then we can just decide to > extend the development cycle another few months."4.3 with some bug fixes" doesn''t necessarily mean it''s not worth releasing ;-)
On Mon, Aug 19, 2013 at 04:17:46PM +0100, Ian Campbell wrote:> Maybe there are other driver which this didn''t affect, evtchn etc > perhaps? I wonder if it is worth init time Xen code synthesising some > uevents iff running on Xen to make these get loaded...evtchn and privcmd are not auto-loaded. This patch was strictly for backends. But it should be possible to create a platform device for xen that triggers loading of them. Could be also used to differentiate between control and non-control domain. Bastian -- Live long and prosper. -- Spock, "Amok Time", stardate 3372.7
On Mon, 2013-08-19 at 18:16 +0200, Bastian Blank wrote:> On Mon, Aug 19, 2013 at 04:17:46PM +0100, Ian Campbell wrote: > > Maybe there are other driver which this didn''t affect, evtchn etc > > perhaps? I wonder if it is worth init time Xen code synthesising some > > uevents iff running on Xen to make these get loaded... > > evtchn and privcmd are not auto-loaded. This patch was strictly for > backends.right.> But it should be possible to create a platform device for xen that > triggers loading of them.yes, that''s the sort of thing I was trying to get at with "synthesizing uevents"> Could be also used to differentiate between > control and non-control domain.Hrm, at least evtchn and privcmd are potentially (but not so commonly) usable in normal domU too. I''d be tempted to just load them if running on Xen -- they aren''t exactly huge... Ian.
>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote: > I think as release cycles get shorter, we have to move into thinking > more like the Linux "merge windows": you work on your feature, and when > it''s ready, you target it for a specific merge window.Which - as expressed before - I dislike. Jan
On 08/20/2013 08:28 AM, Jan Beulich wrote:>>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> I think as release cycles get shorter, we have to move into thinking >> more like the Linux "merge windows": you work on your feature, and when >> it''s ready, you target it for a specific merge window. > > Which - as expressed before - I dislike.But I don''t think I ever understood the nature of your dislike -- what is it you like about the longer release cycles, and/or dislike about the shorter ones? -George
>>> On 20.08.13 at 11:49, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 08/20/2013 08:28 AM, Jan Beulich wrote: >>>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote: >>> I think as release cycles get shorter, we have to move into thinking >>> more like the Linux "merge windows": you work on your feature, and when >>> it''s ready, you target it for a specific merge window. >> >> Which - as expressed before - I dislike. > > But I don''t think I ever understood the nature of your dislike -- what > is it you like about the longer release cycles, and/or dislike about the > shorter ones?First of all, the dislike above was regarding the merge window model. That is because I prefer the continuous flow model we got used to, simply because it allows a more consistent work flow (both from a developer and from a committer perspective). As to the shorter release cycles, I''m sure I said before that I see this problematic wrt stable tree management (resulting in either shorter stable tree life cycles or more work due to more branches being maintained) as well as - see above - the worse ratio between normal development flow and a (partially/mostly) frozen tree (after all, the merge window concept just is an extreme form of shortened release cycles, where almost all of the release cycle is spent in feature frozen state). Plus to me the argument of more frequent releases allowing smoother distro adoption doesn''t really count: I would generally expect distros to not ship unpatched versions anyway, so if they''re eager to get a certain feature out to their users, backporting the feature is always an option. And just to clarify - don''t read into this that I may even be advocating a significantly longer release cycle. As we learned with 4.2, anything beyond a year is likely not going to work out well because of too many changes accumulating. Jan
On Thu, 8 Aug 2013, Eric Shelton wrote:> Related to this, is the Xen hypervisor booting under EFI for arm > already?Not yet, but it''s on our todo list.> I assume not, if Linux currently lacks the needed > hypercalls. Does anything arm-specific need to happen in an > EFI-friendly dom0 kernel, given that it is hypercall driven? Is there > a platform for test?It would be great if you could generalize your work enough so that it would at least compile on arm.
On Wed, Aug 14, 2013 at 02:22:24PM +0100, George Dunlap wrote:> On 09/08/13 21:01, Daniel Kiper wrote: > >On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: > > > >[...] > > > >>* Xen EFI feature: Xen can boot from grub.efi > >> owner: Daniel Kiper > >> status: Just begun > >> prognosis: Fair > >I think that you could change that to Good. I am working > >on it. Migration to xbi struct is almost finished and > >multiboot2 protocol works on machines with legacy BIOS. > >Now I am working on multiboot2 protocol for machines > >with EFI. Yesterday, I discovered some issues related > >to memory map passed via this protocol. Sadly it looks > >that taking into account current GRUB2 implementation > >only workaround is available. Final proper solution would > >require some changes in GRUB2. I will do that later. > > > >[...] > > > >>* Guest EFI booting > >> - status: tianocore in-tree, some build problems. > >> Needs new owner. > >I could take over ownership of this but it would have > >lowest priority on my task list now (major stuff only: > >1 - multiboot2 protocl, 2 - EFI support for Xen in Linux > >Kernel, 3 - guest EFI booting). > > OK -- I think for now then I''ll leave it unclaimed, so that if any other > enterprising developers show up they can take a look at it.OK.> >>* Xen EFI feature: pvops dom0 able to make use of EFI run-time > >>services (external) > >> owner: Daniel Kiper > >> status: Just begun > >I am going to start work on it when I finish work on multiboot2 protocol. > > > >Additionally, I think that: > > - new kexec implementation should be added to this list; > > David Vrabel work on this; I think that patches are > > quite mature and need only some polishing, > > - unmodified_drivers should be removed because as I know > > they are not maintained for very long time; if you > > agree I could do that, > > - as I saw there is a quite big mess in directory structure > > used by installed Xen related stuff (especially in /var > > and /usr); I have done some patches for myself but they > > require some improvements to do public release; if you wish > > I could work on this too. > > It''s up to you really -- if you are set on working on it, I''ll put it on > the list; but there is plenty to do othewise. :-) What kinds of changes > did you have in mind in particular?e.g. a lot of stuff is spread over /var and /var/lib. I do not mention that /var should not contain any non standard directory, i.e. xen. Additionally, there are a few directories in /var/lib used by various stuff. I think that all of them should be moved to /var/lib/xen. The same is in /var/run and /usr/share case. There are also other minor issues which are worth to fix. Daniel
Il 13/08/2013 18:19, George Dunlap ha scritto:> On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote: >> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >>> This information will be mirrored on the Xen 4.4 Roadmap wiki page: >>> http://wiki.xen.org/wiki/Xen_Roadmap/4.4 >>> >>> Rather than try to predict precisely what will make it into what >>> release (which was something of a disaster last release), I''m just >>> going to borrow a term from the Agile world and call all uncompleted >>> features the "Backlog". I''ll still track who is doing what, and when >>> we get close, what state things seem to be in. >>> >>> As mentioned in another e-mail, we''ll also be working on improving the >>> regression tester. Feel free to join us. >>> >>> And as always, if you are working on a feature / bug that you want >>> tracked, please respond to this e-mail. >>> >>> = Timeline >>> >>> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >>> 4.3 was released on 9 July. That would give us a release on 9 January >>> 2014. This is fairly close after the Christmas season, so I propose >>> to make the estimated release date later, on 21 January, giving a few >>> extra weeks for the holiday season: >>> >>> * Feature freeze: 18 October 2013 >>> * Code freezing point: 8 November 2013 >>> * First RC: 26 November 2013 >>> * Release: 21 January 2014 >>> >>> Feedback on the estimated dates is welcome. >>> >>> Last updated: 8 August 2013 >>> >>> == Completed =>>> >>> [none] >>> >>> == Open =>>> >>> * xend still in tree >>> >>> * qemu-upstream not freeing pirq >>> > http://www.gossamer-threads.com/lists/xen/devel/281498 >>> status: patches posted >> They did fix the problem Oracle saw and I believe have been >> Tested-and-Acked. > > Thanks -- have they also been applied? > >> >>> * __update_vcpu_system_time if system_time comes out negative >>> >>> * xl pci-detach broken for pv guests? >>> > http://bugs.xenproject.org/xen/bug/12 >>> > kernel doesn''t know about moving into states 7 and 8 >>> status: External >> Didn''t I post a patch for this on Linux - and it is in Linux kernel >> already. > > Great -- thanks for the update. > >>> * Race in PV shutdown between tool detection and shutdown watch >>> > http://www.gossamer-threads.com/lists/xen/devel/282467 >>> > Nothing to do with ACPI >>> status: Probably a bug in Linux xen drivers >>> >>> == Backlog =>>> >>> === Testing coverage ==>>> >>> * Network driver domains >>> @George >>> >>> * new libxl w/ previous versions of xl >>> @IanJ >>> >>> * Host S3 suspend >>> @bguthro >>> >>> * Default [example] XSM policy >>> @Stefano to ask Daniel D >>> >>> * Xen on ARM >>> # hardware >>> @ianc >>> emulator: @stefano to think about it >>> >>> * Storage driver domains >>> @roger >>> >>> * HVM pci passthrough >>> @anthony >>> >>> * Nested virt? >>> @intel (chased by George) >>> >>> * Fix SRIOV test (chase intel) >>> @ianj >>> >>> * Fix bisector to e-mail blame-worthy parties >>> @ianj >>> >>> * Fix xl shutdown >>> @ianj >>> >>> * stub domains >>> @athony >>> >>> === Big ticket items ==>>> >>> * NUMA Memory migration >>> owner: dario@citrix >>> status: in progress >>> >>> * Event channel scalability >>> owner: david@citrix >>> status: RFC v5 submitted >>> Increase limit on event channels (currently 1024 for 32-bit guests, >>> 4096 for 64-bit guests) >> aka FIFO thing right? > > Yep. I''ll make this a bit more clear. > >> >>> * PVH mode (w/ Linux) >>> owner: mukesh@oracle >>> status (Linux): 3rd draft patches posted. >> More like v8. And already Acked - just waiting for ABI to be in some way >> "nailed down". >> >>> status (Xen): v10 posted >>> >>> * ARM stuff: ?? >>> >>> * Meta: PVIO NUMA improvements >>> - NUMA affinity for vcpus >>> owner: Dario >>> - PV guest NUMA interface >>> owner: Elena >>> - Sensible dom0 NUMA layout >>> - Toolstack pinning backend thread / virq to appropraite d0 vcpu >>> >>> * qemu-upstream stubdom, Linux >>> owner: anthony@citrix >>> status: in progress >>> qemu-upstream needs a more fully-featured libc than exists in >>> mini-os. Either work on a minimalist linux-based stubdom with >>> glibc, or port one of the BSD libcs to minios. >>> >>> * qemu-upstream stubdom, BSD libc >>> owner: ianj@citrix >>> >>> * Network performance improvements >>> owner: wei@citrix >>> >>> * Disk performance improvements >> I think you mean blkback and blkfront? >>> * Xen EFI feature: Xen can boot from grub.efi >>> owner: Daniel Kiper >>> status: Just begun >>> prognosis: Fair >>> >>> * libvirt/libxl integration (external) >>> > need a status update >>> - owner: jfehlig@suse, dario@citrix >>> >>> * Default to credit2 >>> - cpu pinning >>> - NUMA affinity >>> - cpu "reservation" >>> >>> * xenperf >>> Owner: Boris Otovsky >>> >>> * blktap3 >>> owner: thanos@citrix >>> status: on hold pending XenServer decision >>> >>> * Nested virtualization on Intel >>> >>> * Nested virtualization on AMD >>> >>> * Make storage migration possible >>> owner: ? >>> status: none >>> There needs to be a way, either via command-line or via some hooks, >>> that someone can build a "storage migration" feature on top of libxl >>> or xl. >>> >>> * Full-VM snapshotting >>> owner: ? >>> status: none >>> Have a way of coordinating the taking and restoring of VM memory and >>> disk snapshots. This would involve some investigation into the best >>> way to accomplish this. >>> >>> * VM Cloning >>> owner: ? >>> status: none >>> Again, a way of coordinating the memory and disk aspects. Research >>> into the best way to do this would probably go along with the >>> snapshotting feature. >>> >>> * xl vm-{export,import} >>> owner: ? >>> status: none >>> Allow xl to import and export VMs to other formats; particularly >>> ovf, perhaps the XenServer format, or more. >>> >>> * Memory: Replace PoD with paging mechanism >>> owner: george@citrix >>> status: none >>> >>> * PV audio (audio for stubdom qemu) >>> owner: stefano.panella@citrix >>> status: ? >>> >>> * Wait queues for mm >>> > Needed for more advanced paging schemes >>> owner: ? >>> status: Draft posted Feb 2012; more work to do. >>> >>> * V4V: Inter-domain communication >>> owner (Xen): dominic.curran@citrix.com >>> status (Xen): patches submitted >>> owner (Linux driver): stefano.panella@citrix >>> status (Linux driver): in progress >>> >>> === clean-ups ==>>> >>> * Sort out better memory / ballooning / dom0 autoballooning thing >>> > Don''t forget NUMA angle >>> - Inaccurate / incomplete info from HV >>> >>> * Implement Xen hypervisor dmesg log entry timestamps >>> >>> * Make network driver domains easier to set up / more useful >>> - Default backend (submitted) >>> - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted) >>> - Make it easy to make a device assignable (in discussion) >>> - Automatically start/shutdown (xendomains?) >>> - Pause booting of other domains until network driver domain is up >>> >>> * libxl: More fine-grained control over when to pass through a device >>> > Some IOMMUs are secure; some are merely functional, some are not >>> present. >>> > Allow the adminitrator to set the default >>> >>> * xl does not handle migrate interruption gracefully >>> > If you start a localhost migrate, and press "Ctrl-C" in the >>> middle, >>> > you get two hung domains >>> status: Probably not for 4.3 >>> >>> * libxl / xl does not handle failure of remote qemu gracefully >>> > Easiest way to reproduce: >>> > - set "vncunused=0" and do a local migrate >>> > - The "remote" qemu will fail because the vnc port is in use >>> > The failure isn''t the problem, but everything being stuck >>> afterwards is >>> status: Probably not for 4.3 >>> >>> * mac address changes on reboot if not specified in config file >>> > Needs a robust way to "add" to the config >>> status: Too much for 4.3Are there news about that?>>> >>> * qxl >>> > >>> http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >>> - Uninitialized struct element in qemu >>> - Revert 5479961 to re-enable qxl in xl,libxl >>> - Option in Xen top-level to enable qxl support in qemu tree >>> - Fix sse2 MMIO issueAnthony Perard patch about uninitialized qxl struct element in qemu is on upstream git: http://git.qemu.org/?p=qemu.git;a=commit;h=329f97fc4ff4b533fcd2d8f4eab6c9c2568aed27 I think is good improve spice support not only with qxl for now unfortunately blocked by the problem with SSE support. Vdagent and usb redirection are fully working with xen but not supported by xl now, I tested them manually for over a year and I found no problems caused by xen. I did xl patch for add vdagent support long time ago, here the last version: http://lists.xen.org/archives/html/xen-devel/2013-08/msg02635.html The security question open by Ian Jackson has been answered here: http://lists.xen.org/archives/html/xen-devel/2013-08/msg01438.html So I also made this patch to optionally disable the clipboard sharing: http://lists.xen.org/archives/html/xen-devel/2013-08/msg02651.html About usbredirection I''ll post a new version of patch, for now there is a patch about xl usb2 and usb3 controller support ready: http://lists.xen.org/archives/html/xen-devel/2013-07/msg01101.html Now on xl there is only usb1 controller support but windows 7 domU (and probably also with other windows) doesn''t see it correctly. Consequently it is not working the usb redirection on windows 7, because to have it working it needs the usb2 controller. On ubuntu domU works also with usb1 but based on windows tests I think is good to add usb2 controller support before add spice usb redirection support. Thanks for any reply.>>> >>> * libxl config file >>> >>> * libxl: Don''t use RAW format for "URL"-based qdisks (e.g., >>> rbd:rbd/foo.img) >>> - Figure out whether to use a generic URL or have a specific type >>> for each one >>> - Check existence of disk file for all RAW >>> >>> * Polish up xenbugtool >>> owner: wei.liu2@citrix.com >>> >>> * acpi-related xenstore entries not propagated on migrate >>> > http://www.gossamer-threads.com/lists/xen/devel/282466 >>> > Only used by hvmloader; only a clean-up, not a bug. >>> status: Not for 4.3 >>> >>> * Remove hardcoded mobprobe''s in xencommons >>> owner: Wei Liu >>> status: still in discussion >>> >>> * xl USB pass-through for HVM guests using Qemu USB emulation >>> owner: George >>> status: v6 patch series posted >>> >>> * Rationalized backend scripts >>> owner: roger@citrix >>> status: patches posted >>> >>> * Scripts for driver domains (depends on backend scripts) >>> owner: roger@citrix >>> status: >>> >>> * Multi-vector PCI MSI (support at least for Dom0) >>> owner: jan@suse >>> status: Patches posted for Intel; AMD not yet done >> And patches for Linux upstream are missing. > > > >> >>> * xl: passing more defaults in configuration in xl.conf >>> owner: ? >>> 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. >>> >>> * xl PVUSB pass-through for PV guests >>> * xl PVUSB pass-through for HVM guests >>> owner: George >>> status: ? >>> xm/xend supports PVUSB pass-through to guests with PVUSB drivers >>> (both PV and HVM guests). >>> - port the xm/xend functionality to xl. >>> - this PVUSB feature does not require support or emulation from >>> Qemu. >>> - upstream the Linux frontend/backend drivers. Current >>> work-in-progress versions are in Konrad''s git tree. >> Which is to say I hadn''t actually touched them in a year. > > Yeah, I was under the impression they weren''t really going anywhere. > If you think this is unclear, feel free to suggest alternate wording. > >> >>> - James Harper''s GPLPV drivers for Windows include PVUSB frontend >>> drivers. >>> >>> * Guest EFI booting >>> - status: tianocore in-tree, some build problems. >>> Needs new owner. >>> >>> * Xen EFI feature: pvops dom0 able to make use of EFI run-time >>> services (external) >>> owner: Daniel Kiper >>> status: Just begun >>> >>> * Serial console improvements >>> owner: ? >>> status: Stalled (see below) >>> -xHCI debug port (Needs hardware) >>> -Firewire (needs hardware) >>> >> I would like also to put GPU passthrough working here. > > What aspect do you mean? > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Thu, Aug 8, 2013 at 12:09 PM, George Dunlap <George.Dunlap@eu.citrix.com>wrote:> This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I''m just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I''ll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we''ll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome. > > Last updated: 8 August 2013 > > > > == Backlog => >This is a late entry. * libxl support for Remus @shriram status: memory checkpointing - done. network buffering - patches posted. disk replication support using DRBD - TODO _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
George Dunlap wrote:> This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I''m just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I''ll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we''ll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome. > > Last updated: 8 August 2013 > > == Completed => > [none] > > == Open => > * xend still in tree > > * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches posted > > * __update_vcpu_system_time if system_time comes out negative > > * xl pci-detach broken for pv guests? > > http://bugs.xenproject.org/xen/bug/12 > > kernel doesn''t know about moving into states 7 and 8 > status: External > > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > Nothing to do with ACPI > status: Probably a bug in Linux xen drivers > > == Backlog => > === Testing coverage ==> > * Network driver domains > @George > > * new libxl w/ previous versions of xl > @IanJ > > * Host S3 suspend > @bguthro > > * Default [example] XSM policy > @Stefano to ask Daniel D > > * Xen on ARM > # hardware > @ianc > emulator: @stefano to think about it > > * Storage driver domains > @roger > > * HVM pci passthrough > @anthony > > * Nested virt? > @intel (chased by George) > > * Fix SRIOV test (chase intel) > @ianj > > * Fix bisector to e-mail blame-worthy parties > @ianj > > * Fix xl shutdown > @ianj > > * stub domains > @athony > > === Big ticket items ==> > * NUMA Memory migration > owner: dario@citrix > status: in progress > > * Event channel scalability > owner: david@citrix > status: RFC v5 submitted > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests) > > * PVH mode (w/ Linux) > owner: mukesh@oracle > status (Linux): 3rd draft patches posted. > status (Xen): v10 posted > > * ARM stuff: ?? > > * Meta: PVIO NUMA improvements > - NUMA affinity for vcpus > owner: Dario > - PV guest NUMA interface > owner: Elena > - Sensible dom0 NUMA layout > - Toolstack pinning backend thread / virq to appropraite d0 vcpu > > * qemu-upstream stubdom, Linux > owner: anthony@citrix > status: in progress > qemu-upstream needs a more fully-featured libc than exists in > mini-os. Either work on a minimalist linux-based stubdom with > glibc, or port one of the BSD libcs to minios. > > * qemu-upstream stubdom, BSD libc > owner: ianj@citrix >There is no mention of updating to the latest upstream qemu. Wasn''t there talk of updating to the latest qemu release at the beginning of a Xen development cycle?> * Network performance improvements > owner: wei@citrix > > * Disk performance improvements > > * Xen EFI feature: Xen can boot from grub.efi > owner: Daniel Kiper > status: Just begun > prognosis: Fair > > * libvirt/libxl integration (external) > > need a status update > - owner: jfehlig@suse, dario@citrix >The main items missing in the libvirt libxl driver wrt the legacy Xen driver are migration and PCI passthrough. But patches for both of these features have been posted to the libvirt dev list https://www.redhat.com/archives/libvir-list/2013-September/msg00667.html https://www.redhat.com/archives/libvir-list/2013-September/msg00660.html libvirt is on a monthly release cycle, so there will certainly be a release containing these patches before Xen 4.4. There are also patches in the works to add functionality that was generally not possible in the legacy Xen driver, e.g. integration with libvirt''s lock manager, providing protection of disk resources. I''m also working on patches to improve concurrency in the driver. Slowly, with each libvirt release, the libxl driver is improving. Regards, Jim
>>> On 17.09.13 at 17:12, Jim Fehlig <jfehlig@suse.com> wrote: > George Dunlap wrote: >> * qemu-upstream stubdom, BSD libc >> owner: ianj@citrix >> > > There is no mention of updating to the latest upstream qemu. Wasn''t > there talk of updating to the latest qemu release at the beginning of a > Xen development cycle?Talking of which - shouldn''t we also update to the latest stable SeaBIOS for the new release? Jan
On Tue, 2013-09-17 at 16:39 +0100, Jan Beulich wrote:> >>> On 17.09.13 at 17:12, Jim Fehlig <jfehlig@suse.com> wrote: > > George Dunlap wrote: > >> * qemu-upstream stubdom, BSD libc > >> owner: ianj@citrix > >> > > > > There is no mention of updating to the latest upstream qemu. Wasn''t > > there talk of updating to the latest qemu release at the beginning of a > > Xen development cycle? > > Talking of which - shouldn''t we also update to the latest stable > SeaBIOS for the new release?Yes we should. Which means I should, just need to get around to it :-( Ian.
On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches postedDid this one get fixed yet? -George
On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * xl pci-detach broken for pv guests? > > http://bugs.xenproject.org/xen/bug/12 > > kernel doesn''t know about moving into states 7 and 8 > status: External > > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > Nothing to do with ACPI > status: Probably a bug in Linux xen driversKonrad, I think you were looking at these -- has there been any update? -George
On Wed, Sep 18, 2013 at 12:16:29PM +0100, George Dunlap wrote:> On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > > * qemu-upstream not freeing pirq > > > http://www.gossamer-threads.com/lists/xen/devel/281498 > > status: patches posted > > Did this one get fixed yet?I believe so. We are just waiting for Stefano to merge it in.> > -George
On Wed, Sep 18, 2013 at 12:27:15PM +0100, George Dunlap wrote:> On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > > > * xl pci-detach broken for pv guests? > > > http://bugs.xenproject.org/xen/bug/12 > > > kernel doesn''t know about moving into states 7 and 8 > > status: External > > > > * Race in PV shutdown between tool detection and shutdown watch > > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > > Nothing to do with ACPI > > status: Probably a bug in Linux xen drivers > > Konrad, I think you were looking at these -- has there been any update?Oh boy. I need to replicate this. Thanks for the remainder.> > -George