For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider
the following changesets from -unstable for backporting:
For 4.0 and 4.1:
24155 (x86/IO-APIC: refine EOI-ing of migrating level interrupts)
24190 (x86/mm: change return code for log-dirty disabling)
24201 (x86: small fixes to pcpu platform op handling)
24282 (x86/mm: Don''t lose track of the log dirty bitmap)
24389 (x86, amd: Disable GartTlbWlkErr when BIOS forgets it)
24417 (x86/emulator: workaround for AMD erratum 573)
24535 (x86/vMSI: miscellaneous fixes)
24888 (passthrough: release assigned PCI devices earlier during domain shutdown)
For 4.1:
23853+23955 (pv cpuid emulation for xsave)
23908 (p2m: query/modify p2mt with p2m_lock held)
24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring
23900 [kzalloc])
24157 (x86/xsave: provide guests with finit-like environment)
24357 (tools/firmware: remove "_PS0/3" Method)
24448 (x86/passthrough: don''t leak guest IRQs)
24517 (Move IOMMU faults handling into softirq for VT-d)
24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi)
24701 (Fix error recovery path in __gnttab_map_grant_ref)
24883 (x86/mm: Don''t check for invalid bits in non-present PTEs)
24950 (Grant table: fix a bug when grant copying a previous grant mapped page)
For 4.0 (already in 4.1)
24168 (x86/vioapic: clear remote IRR when switching RTE to edge triggered mode)
24193 (Trivial fix for rc val in hap track dirty vram)
24344+24345 (tools/x86_64: Fix cpuid() inline asm to not clobber
stack''s red zone)
24358 (KEXEC: fix kexec_get_range_compat to fail vocally)
24690 (x86: avoid deadlock after a PCI SERR NMI)
24742 (gnttab: miscellaneous fixes)
Especially some of the 4.0 ones may be non-trivial backports - already
backported version can be provided.
Thanks, Jan
On 06/03/2012 10:13, "Jan Beulich" <JBeulich@suse.com> wrote:> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider > the following changesets from -unstable for backporting:I will take a look and report back on ones that need non-trivial porting effort. -- Keir> For 4.0 and 4.1: > 24155 (x86/IO-APIC: refine EOI-ing of migrating level interrupts) > 24190 (x86/mm: change return code for log-dirty disabling) > 24201 (x86: small fixes to pcpu platform op handling) > 24282 (x86/mm: Don''t lose track of the log dirty bitmap) > 24389 (x86, amd: Disable GartTlbWlkErr when BIOS forgets it) > 24417 (x86/emulator: workaround for AMD erratum 573) > 24535 (x86/vMSI: miscellaneous fixes) > 24888 (passthrough: release assigned PCI devices earlier during domain > shutdown) > > For 4.1: > 23853+23955 (pv cpuid emulation for xsave) > 23908 (p2m: query/modify p2mt with p2m_lock held) > 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring > 23900 [kzalloc]) > 24157 (x86/xsave: provide guests with finit-like environment) > 24357 (tools/firmware: remove "_PS0/3" Method) > 24448 (x86/passthrough: don''t leak guest IRQs) > 24517 (Move IOMMU faults handling into softirq for VT-d) > 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi) > 24701 (Fix error recovery path in __gnttab_map_grant_ref) > 24883 (x86/mm: Don''t check for invalid bits in non-present PTEs) > 24950 (Grant table: fix a bug when grant copying a previous grant mapped page) > > For 4.0 (already in 4.1) > 24168 (x86/vioapic: clear remote IRR when switching RTE to edge triggered > mode) > 24193 (Trivial fix for rc val in hap track dirty vram) > 24344+24345 (tools/x86_64: Fix cpuid() inline asm to not clobber stack''s red > zone) > 24358 (KEXEC: fix kexec_get_range_compat to fail vocally) > 24690 (x86: avoid deadlock after a PCI SERR NMI) > 24742 (gnttab: miscellaneous fixes) > > Especially some of the 4.0 ones may be non-trivial backports - already > backported version can be provided. > > Thanks, Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On 06/03/12 10:13, Jan Beulich wrote:> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider > the following changesets from -unstable for backporting:May I add the following suggestions. These are all patches which we have cherry picked for XenServer. The changesets with *''s are not a clean backport, and I can provide patches against Xen-4.1.x for them.> For 4.0 and 4.1: > 24155 (x86/IO-APIC: refine EOI-ing of migrating level interrupts) > 24190 (x86/mm: change return code for log-dirty disabling) > 24201 (x86: small fixes to pcpu platform op handling) > 24282 (x86/mm: Don''t lose track of the log dirty bitmap) > 24389 (x86, amd: Disable GartTlbWlkErr when BIOS forgets it) > 24417 (x86/emulator: workaround for AMD erratum 573) > 24535 (x86/vMSI: miscellaneous fixes) > 24888 (passthrough: release assigned PCI devices earlier during domain shutdown) > > For 4.1:23554 (shadow: adjust early heuristics) 23610 (x86: consolidate cpu_core_id and phys_proc_id) 23611 (AMD: core-pair detection) 23795* (x86: ICH10 Quirks) - We have just had to backport this for a customer escalation on xen-3.x, if it would be accepted there 23811* (UART: dont write spurious char)> 23853+23955 (pv cpuid emulation for xsave) > 23908 (p2m: query/modify p2mt with p2m_lock held)23936*,23937,23938*,23939,23940,23941 (Various ocaml fixes)> 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring > 23900 [kzalloc]) > 24157 (x86/xsave: provide guests with finit-like environment)24320 (ocaml: release global lock during some hypercalls)> 24357 (tools/firmware: remove "_PS0/3" Method)24414 (oxenstored: install configuration file)> 24448 (x86/passthrough: don''t leak guest IRQs)(I can provide a backported version of 24448 if required)> 24517 (Move IOMMU faults handling into softirq for VT-d)24518 (sched_credit: performance improvement)> 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi)24542, 24543, 24570, 24571 (xenoprof fixes)> 24701 (Fix error recovery path in __gnttab_map_grant_ref)24709 (libxc: replace malloc with alloca on hot path) 24832 (libxc: remove tests of alloca() return value) 24870* (IOAPIC: prevent directed EOI support trashing io_ack mode)> 24883 (x86/mm: Don''t check for invalid bits in non-present PTEs) > 24950 (Grant table: fix a bug when grant copying a previous grant mapped page) > > For 4.0 (already in 4.1) > 24168 (x86/vioapic: clear remote IRR when switching RTE to edge triggered mode) > 24193 (Trivial fix for rc val in hap track dirty vram) > 24344+24345 (tools/x86_64: Fix cpuid() inline asm to not clobber stack''s red zone) > 24358 (KEXEC: fix kexec_get_range_compat to fail vocally) > 24690 (x86: avoid deadlock after a PCI SERR NMI) > 24742 (gnttab: miscellaneous fixes) > > Especially some of the 4.0 ones may be non-trivial backports - already > backported version can be provided. > > Thanks, Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
I would like to nominate 2 patches to be backported to Xen 4.1: 24458 (libxl: print out vifname in create dryrun.) 24459 (libxl: write vifname in xenstore if set.) Thanks, Roderick Colenbrander On Tue, Mar 6, 2012 at 3:04 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:> On 06/03/12 10:13, Jan Beulich wrote: >> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >> the following changesets from -unstable for backporting: > May I add the following suggestions. These are all patches which we > have cherry picked for XenServer. > > The changesets with *''s are not a clean backport, and I can provide > patches against Xen-4.1.x for them. > >> For 4.0 and 4.1: >> 24155 (x86/IO-APIC: refine EOI-ing of migrating level interrupts) >> 24190 (x86/mm: change return code for log-dirty disabling) >> 24201 (x86: small fixes to pcpu platform op handling) >> 24282 (x86/mm: Don''t lose track of the log dirty bitmap) >> 24389 (x86, amd: Disable GartTlbWlkErr when BIOS forgets it) >> 24417 (x86/emulator: workaround for AMD erratum 573) >> 24535 (x86/vMSI: miscellaneous fixes) >> 24888 (passthrough: release assigned PCI devices earlier during domain shutdown) >> >> For 4.1: > 23554 (shadow: adjust early heuristics) > 23610 (x86: consolidate cpu_core_id and phys_proc_id) > 23611 (AMD: core-pair detection) > 23795* (x86: ICH10 Quirks) - We have just had to backport this for a > customer escalation on xen-3.x, if it would be accepted there > 23811* (UART: dont write spurious char) >> 23853+23955 (pv cpuid emulation for xsave) >> 23908 (p2m: query/modify p2mt with p2m_lock held) > 23936*,23937,23938*,23939,23940,23941 (Various ocaml fixes) >> 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring >> 23900 [kzalloc]) >> 24157 (x86/xsave: provide guests with finit-like environment) > 24320 (ocaml: release global lock during some hypercalls) >> 24357 (tools/firmware: remove "_PS0/3" Method) > 24414 (oxenstored: install configuration file) >> 24448 (x86/passthrough: don''t leak guest IRQs) > (I can provide a backported version of 24448 if required) >> 24517 (Move IOMMU faults handling into softirq for VT-d) > 24518 (sched_credit: performance improvement) >> 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi) > 24542, 24543, 24570, 24571 (xenoprof fixes) >> 24701 (Fix error recovery path in __gnttab_map_grant_ref) > 24709 (libxc: replace malloc with alloca on hot path) > 24832 (libxc: remove tests of alloca() return value) > 24870* (IOAPIC: prevent directed EOI support trashing io_ack mode) >> 24883 (x86/mm: Don''t check for invalid bits in non-present PTEs) >> 24950 (Grant table: fix a bug when grant copying a previous grant mapped page) >> >> For 4.0 (already in 4.1) >> 24168 (x86/vioapic: clear remote IRR when switching RTE to edge triggered mode) >> 24193 (Trivial fix for rc val in hap track dirty vram) >> 24344+24345 (tools/x86_64: Fix cpuid() inline asm to not clobber stack''s red zone) >> 24358 (KEXEC: fix kexec_get_range_compat to fail vocally) >> 24690 (x86: avoid deadlock after a PCI SERR NMI) >> 24742 (gnttab: miscellaneous fixes) >> >> Especially some of the 4.0 ones may be non-trivial backports - already >> backported version can be provided. >> >> Thanks, Jan >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > -- > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer > T: +44 (0)1223 225 900, http://www.citrix.com > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
All applied, except: On 06/03/2012 10:13, "Jan Beulich" <JBeulich@suse.com> wrote:> 24535 (x86/vMSI: miscellaneous fixes)Applied to 4.1, but does not easily apply to 4.0. You''ll need to provide a patch against 4.0-testing.> 24888 (passthrough: release assigned PCI devices earlier during domain > shutdown)This one applied, but I see a bug in the original xen-unstable patch. In XEN_DOMCTL_assign_device you break on d->is_dying, but do not put_domain(d). You should go fix that in xen-unstable.> 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring > 23900 [kzalloc])Doesn''t easily apply. Need a patch against 4.1-testing.> 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi)Depends on other xen-unstable patches which refactor AMD IOMMU event handling. You''d need to provide a manual backport of this for 4.1-testing.> 24690 (x86: avoid deadlock after a PCI SERR NMI)There is no PCI SERR NMI handling in 4.0-testing. It would also need backporting. -- Keir
On 06/03/2012 11:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:> On 06/03/12 10:13, Jan Beulich wrote: >> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >> the following changesets from -unstable for backporting: > May I add the following suggestions. These are all patches which we > have cherry picked for XenServer.All applied except as follows:> 23936*,23937,23938*,23939,23940,23941 (Various ocaml fixes) > 24320 (ocaml: release global lock during some hypercalls) > 24414 (oxenstored: install configuration file)These need to be Acked or backported by a toolstack maintainer.> 24542, 24543, 24570, 24571 (xenoprof fixes)These changesets do not relate to xenoprof??> 24870* (IOAPIC: prevent directed EOI support trashing io_ack mode)Too hard to backport. Please provide your backported version. -- Keir
On 07/03/2012 07:25, "Roderick Colenbrander" <thunderbird2k@gmail.com> wrote:> I would like to nominate 2 patches to be backported to Xen 4.1: > 24458 (libxl: print out vifname in create dryrun.) > 24459 (libxl: write vifname in xenstore if set.)These need to be Acked or backported by a toolstack maintainer. -- Keir> Thanks, > Roderick Colenbrander > > On Tue, Mar 6, 2012 at 3:04 AM, Andrew Cooper <andrew.cooper3@citrix.com> > wrote: >> On 06/03/12 10:13, Jan Beulich wrote: >>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >>> the following changesets from -unstable for backporting: >> May I add the following suggestions. These are all patches which we >> have cherry picked for XenServer. >> >> The changesets with *''s are not a clean backport, and I can provide >> patches against Xen-4.1.x for them. >> >>> For 4.0 and 4.1: >>> 24155 (x86/IO-APIC: refine EOI-ing of migrating level interrupts) >>> 24190 (x86/mm: change return code for log-dirty disabling) >>> 24201 (x86: small fixes to pcpu platform op handling) >>> 24282 (x86/mm: Don''t lose track of the log dirty bitmap) >>> 24389 (x86, amd: Disable GartTlbWlkErr when BIOS forgets it) >>> 24417 (x86/emulator: workaround for AMD erratum 573) >>> 24535 (x86/vMSI: miscellaneous fixes) >>> 24888 (passthrough: release assigned PCI devices earlier during domain >>> shutdown) >>> >>> For 4.1: >> 23554 (shadow: adjust early heuristics) >> 23610 (x86: consolidate cpu_core_id and phys_proc_id) >> 23611 (AMD: core-pair detection) >> 23795* (x86: ICH10 Quirks) - We have just had to backport this for a >> customer escalation on xen-3.x, if it would be accepted there >> 23811* (UART: dont write spurious char) >>> 23853+23955 (pv cpuid emulation for xsave) >>> 23908 (p2m: query/modify p2mt with p2m_lock held) >> 23936*,23937,23938*,23939,23940,23941 (Various ocaml fixes) >>> 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring >>> 23900 [kzalloc]) >>> 24157 (x86/xsave: provide guests with finit-like environment) >> 24320 (ocaml: release global lock during some hypercalls) >>> 24357 (tools/firmware: remove "_PS0/3" Method) >> 24414 (oxenstored: install configuration file) >>> 24448 (x86/passthrough: don''t leak guest IRQs) >> (I can provide a backported version of 24448 if required) >>> 24517 (Move IOMMU faults handling into softirq for VT-d) >> 24518 (sched_credit: performance improvement) >>> 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi) >> 24542, 24543, 24570, 24571 (xenoprof fixes) >>> 24701 (Fix error recovery path in __gnttab_map_grant_ref) >> 24709 (libxc: replace malloc with alloca on hot path) >> 24832 (libxc: remove tests of alloca() return value) >> 24870* (IOAPIC: prevent directed EOI support trashing io_ack mode) >>> 24883 (x86/mm: Don''t check for invalid bits in non-present PTEs) >>> 24950 (Grant table: fix a bug when grant copying a previous grant mapped >>> page) >>> >>> For 4.0 (already in 4.1) >>> 24168 (x86/vioapic: clear remote IRR when switching RTE to edge triggered >>> mode) >>> 24193 (Trivial fix for rc val in hap track dirty vram) >>> 24344+24345 (tools/x86_64: Fix cpuid() inline asm to not clobber stack''s red >>> zone) >>> 24358 (KEXEC: fix kexec_get_range_compat to fail vocally) >>> 24690 (x86: avoid deadlock after a PCI SERR NMI) >>> 24742 (gnttab: miscellaneous fixes) >>> >>> Especially some of the 4.0 ones may be non-trivial backports - already >>> backported version can be provided. >>> >>> Thanks, Jan >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >> -- >> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer >> T: +44 (0)1223 225 900, http://www.citrix.com >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
>>> On 07.03.12 at 10:18, Keir Fraser <keir@xen.org> wrote: > All applied, except:Thanks. Let''s wait for the simple ones to get through the stage test first before throwing in such that are more involved.> On 06/03/2012 10:13, "Jan Beulich" <JBeulich@suse.com> wrote: > >> 24535 (x86/vMSI: miscellaneous fixes) > > Applied to 4.1, but does not easily apply to 4.0. You''ll need to provide a > patch against 4.0-testing. > >> 24888 (passthrough: release assigned PCI devices earlier during domain >> shutdown) > > This one applied, but I see a bug in the original xen-unstable patch. In > XEN_DOMCTL_assign_device you break on d->is_dying, but do not put_domain(d). > You should go fix that in xen-unstable.24983:f234e34ea28f>> 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring >> 23900 [kzalloc]) > > Doesn''t easily apply. Need a patch against 4.1-testing. > >> 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi) > > Depends on other xen-unstable patches which refactor AMD IOMMU event > handling. You''d need to provide a manual backport of this for 4.1-testing. > >> 24690 (x86: avoid deadlock after a PCI SERR NMI) > > There is no PCI SERR NMI handling in 4.0-testing. It would also need > backporting.Oh, sorry, I overlooked that this requires 22949 as prerequisite. But then again maybe we might just leave it as-is in 4.0 (and have distros that care, like ours, continue to carry the patches themselves - after all when providing the list I didn''t pick everything we backported anyway, just those that I considered more of a fix than an enhancement). Jan
On 07/03/12 09:43, Keir Fraser wrote:> On 06/03/2012 11:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote: > >> On 06/03/12 10:13, Jan Beulich wrote: >>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >>> the following changesets from -unstable for backporting: >> May I add the following suggestions. These are all patches which we >> have cherry picked for XenServer. > All applied except as follows: > >> 23936*,23937,23938*,23939,23940,23941 (Various ocaml fixes) >> 24320 (ocaml: release global lock during some hypercalls) >> 24414 (oxenstored: install configuration file) > These need to be Acked or backported by a toolstack maintainer. > >> 24542, 24543, 24570, 24571 (xenoprof fixes) > These changesets do not relate to xenoprof??So they are not. It appears that there was an off-by-6 numbering error in our patch queue for these patches. Apologies for that. The numbers were in fact 24536,24537,24564,24565.>> 24870* (IOAPIC: prevent directed EOI support trashing io_ack mode) > Too hard to backport. Please provide your backported version.Attached.> -- Keir > >-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 07/03/2012 10:44, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:> On 07/03/12 09:43, Keir Fraser wrote: >> On 06/03/2012 11:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote: >> >>> On 06/03/12 10:13, Jan Beulich wrote: >>>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >>>> the following changesets from -unstable for backporting: >>> May I add the following suggestions. These are all patches which we >>> have cherry picked for XenServer. >> All applied except as follows: >> >>> 23936*,23937,23938*,23939,23940,23941 (Various ocaml fixes) >>> 24320 (ocaml: release global lock during some hypercalls) >>> 24414 (oxenstored: install configuration file) >> These need to be Acked or backported by a toolstack maintainer. >> >>> 24542, 24543, 24570, 24571 (xenoprof fixes) >> These changesets do not relate to xenoprof?? > > So they are not. It appears that there was an off-by-6 numbering error > in our patch queue for these patches. Apologies for that. > > The numbers were in fact 24536,24537,24564,24565.Applied.>>> 24870* (IOAPIC: prevent directed EOI support trashing io_ack mode) >> Too hard to backport. Please provide your backported version. > > Attached.And applied. -- Keir>> -- Keir >> >>
>>> On 07.03.12 at 11:59, Keir Fraser <keir@xen.org> wrote: > On 07/03/2012 10:44, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote: >> So they are not. It appears that there was an off-by-6 numbering error >> in our patch queue for these patches. Apologies for that. >> >> The numbers were in fact 24536,24537,24564,24565. > > Applied.Hmm, if you apply 24537, then you should also pull in 24971 (perhaps once it made it through the stage tests). Jan
On 07/03/12 11:06, Jan Beulich wrote:>>>> On 07.03.12 at 11:59, Keir Fraser <keir@xen.org> wrote: >> On 07/03/2012 10:44, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote: >>> So they are not. It appears that there was an off-by-6 numbering error >>> in our patch queue for these patches. Apologies for that. >>> >>> The numbers were in fact 24536,24537,24564,24565. >> Applied. > Hmm, if you apply 24537, then you should also pull in 24971 (perhaps > once it made it through the stage tests). > > JanYes - I had my eye on that patch. I will pull it through after it passes the tests. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On Wed, 2012-03-07 at 05:44 -0500, Andrew Cooper wrote:> On 07/03/12 09:43, Keir Fraser wrote: > > On 06/03/2012 11:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote: > >> 24542, 24543, 24570, 24571 (xenoprof fixes) > > These changesets do not relate to xenoprof?? > > So they are not. It appears that there was an off-by-6 numbering error > in our patch queue for these patches. Apologies for that.These rev numbers are not globally meaningful, you need to use the node hash if you want to reliably refer to particular changesets.
>>> On 07.03.12 at 10:18, Keir Fraser <keir@xen.org> wrote: >> 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring >> 23900 [kzalloc]) > > Doesn''t easily apply. Need a patch against 4.1-testing. > >> 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi) > > Depends on other xen-unstable patches which refactor AMD IOMMU event > handling. You''d need to provide a manual backport of this for 4.1-testing.All attached. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 08/03/2012 10:00, "Jan Beulich" <JBeulich@suse.com> wrote:>>>> On 07.03.12 at 10:18, Keir Fraser <keir@xen.org> wrote: >>> 24156 (x86/IRQ: prevent vector sharing within IO-APICs, requiring >>> 23900 [kzalloc]) >> >> Doesn''t easily apply. Need a patch against 4.1-testing. >> >>> 24527 (iommu: Move IOMMU faults handling into softirq for AMD-Vi) >> >> Depends on other xen-unstable patches which refactor AMD IOMMU event >> handling. You''d need to provide a manual backport of this for 4.1-testing. > > All attached.And all now applied. -- Keir> Jan >
On 07/03/12 19:38, Ian Campbell wrote:> On Wed, 2012-03-07 at 05:44 -0500, Andrew Cooper wrote: >> On 07/03/12 09:43, Keir Fraser wrote: >>> On 06/03/2012 11:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote: >>>> 24542, 24543, 24570, 24571 (xenoprof fixes) >>> These changesets do not relate to xenoprof?? >> So they are not. It appears that there was an off-by-6 numbering error >> in our patch queue for these patches. Apologies for that. > These rev numbers are not globally meaningful, you need to use the node > hash if you want to reliably refer to particular changesets.The node hashes were correct, which is how I verified the patches after the error was noticed. I just naively assumed that the patches in the "explicitly from xen-unstable.hg" section would have the correct rev numbers as well. I have checked all other patches and am now fairly happy that they are correct, and shall be more vigilant as new patches are being added. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On 08/03/2012 10:38, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:>>> So they are not. It appears that there was an off-by-6 numbering error >>> in our patch queue for these patches. Apologies for that. >> These rev numbers are not globally meaningful, you need to use the node >> hash if you want to reliably refer to particular changesets. > > The node hashes were correct, which is how I verified the patches after > the error was noticed. I just naively assumed that the patches in the > "explicitly from xen-unstable.hg" section would have the correct rev > numbers as well. > > I have checked all other patches and am now fairly happy that they are > correct, and shall be more vigilant as new patches are being added.I certainly prefer changeset numbers, with reference to xenbits.xen.org master tree, when dealing with lists of patches. Just seem easier for me to deal with. They just need to be correct is all! -- Keir
>>> On 07.03.12 at 10:18, Keir Fraser <keir@xen.org> wrote: >> 24535 (x86/vMSI: miscellaneous fixes) > > Applied to 4.1, but does not easily apply to 4.0. You''ll need to provide a > patch against 4.0-testing.Here you go. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 08/03/2012 10:45, "Jan Beulich" <JBeulich@suse.com> wrote:>>>> On 07.03.12 at 10:18, Keir Fraser <keir@xen.org> wrote: >>> 24535 (x86/vMSI: miscellaneous fixes) >> >> Applied to 4.1, but does not easily apply to 4.0. You''ll need to provide a >> patch against 4.0-testing. > > Here you go.Applied.> Jan >
Roderick Colenbrander writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> I would like to nominate 2 patches to be backported to Xen 4.1:
> 24458 (libxl: print out vifname in create dryrun.)
> 24459 (libxl: write vifname in xenstore if set.)
I have backported 24458. 24459 looks fine to be for a backport but
doesn''t apply cleanly to 4.1. Would you care to provide a backported
version ?
Thanks,
Ian.
Keir Fraser writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> On 06/03/2012 11:04, "Andrew Cooper"
<andrew.cooper3@citrix.com> wrote:
> > 23936*,23937,23938*,23939,23940,23941 (Various ocaml fixes)
> > 24320 (ocaml: release global lock during some hypercalls)
> > 24414 (oxenstored: install configuration file)
>
> These need to be Acked or backported by a toolstack maintainer.
Thanks, Keir.
Andrew, how did you construct this list of proposed backports ?
It seems to be rather a mixed bag.
I''m certainly very reluctant to throw something like
23936:cdb34816a40a tools/ocaml: Rename the ocaml libraries
into a supposedly stable tree!
Ian.
On Wed, Mar 14, 2012 at 12:50 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Roderick Colenbrander writes ("Re: [Xen-devel] backport requests for 4.x-testing"): >> I would like to nominate 2 patches to be backported to Xen 4.1: >> 24458 (libxl: print out vifname in create dryrun.) >> 24459 (libxl: write vifname in xenstore if set.) > > I have backported 24458. 24459 looks fine to be for a backport but > doesn''t apply cleanly to 4.1. Would you care to provide a backported > version ?Sorry, just feel bored and here is the backport version which I not sure whether is it right :p Mind to check? Thanks. libxl: write vifname in xenstore if set. Simple fix to enable user to specify vif names. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Campbell <ian.campbell.com> xen-unstable changeset: 24459:caf9753d4cc1 Backport-requested-by: Roderick Colenbrander <thunderbird2k@gmail.com> diff -urN a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c 2012-03-14 00:49:03.000000000 +0800 +++ b/tools/libxl/libxl.c 2012-03-14 01:15:27.000000000 +0800 @@ -1229,6 +1229,10 @@ flexarray_append(back, libxl__sprintf(&gc, "%d", 1)); flexarray_append(back, "script"); flexarray_append(back, nic->script); + if (nic->ifname) { + flexarray_append(back, "vifname"); + flexarray_append(back, nic->ifname); + } flexarray_append(back, "mac"); flexarray_append(back, libxl__sprintf(&gc, "%02x:%02x:%02x:%02x:%02x:%02x", nic->mac[0], nic->mac[1], nic->mac[2],> > Thanks, > Ian.Thanks. Kindest regards, Giam Teck Choon
Hi, How about cs 24595? xl: fix a couple of memory leaks at http://xenbits.xensource.com/hg/staging/xen-unstable.hg/rev/f204ead7d9e4 Thanks. Kindest regards, Giam Teck Choon
Sorry, one more cs 24593 ? Thanks. Kindest regards, Giam Teck Choon
Teck Choon Giam writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> xl: fix a couple of memory leaks at
> http://xenbits.xensource.com/hg/staging/xen-unstable.hg/rev/f204ead7d9e4
Even the dolog leak is probably not really important for xl users
because xl produces a pretty bounded amount of log output. So I don''t
see the benefit of a backport really.
Ian.
Teck Choon Giam writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> Sorry, one more cs 24593 ?
That one looks reasonable. Done.
Ian.
Teck Choon Giam writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> libxl: write vifname in xenstore if set.
>
> Simple fix to enable user to specify vif names.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell.com>
> xen-unstable changeset: 24459:caf9753d4cc1
> Backport-requested-by: Roderick Colenbrander
<thunderbird2k@gmail.com>
Thanks, this looks good but I really ought to ask you for your
signoff. See http://wiki.xen.org/wiki/Submitting_Xen_Patches
Ian.
On Wed, Mar 14, 2012 at 7:37 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"): >> libxl: write vifname in xenstore if set. >> >> Simple fix to enable user to specify vif names. >> >> Signed-off-by: Wei Liu <wei.liu2@citrix.com> >> Acked-by: Ian Campbell <ian.campbell.com> >> xen-unstable changeset: 24459:caf9753d4cc1 >> Backport-requested-by: Roderick Colenbrander <thunderbird2k@gmail.com> > > Thanks, this looks good but I really ought to ask you for your > signoff. See http://wiki.xen.org/wiki/Submitting_Xen_Patches > > Ian.Sorry, attached is the backport patch. I added new lines to follow the original changeset in unstable. For your review please. Thanks. Kindest regards, Giam Teck Choon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
libxl: write vifname in xenstore if set.
Simple fix to enable user to specify vif names.
xen-unstable changeset: 24459:caf9753d4cc1
Backport-requested-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
---
tools/libxl/libxl.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 902f282..19ef6a0 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1229,6 +1229,12 @@ int libxl_device_nic_add(libxl_ctx *ctx,
uint32_t domid, libxl_device_nic *nic)
flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
flexarray_append(back, "script");
flexarray_append(back, nic->script);
+
+ if (nic->ifname) {
+ flexarray_append(back, "vifname");
+ flexarray_append(back, nic->ifname);
+ }
+
flexarray_append(back, "mac");
flexarray_append(back, libxl__sprintf(&gc,
"%02x:%02x:%02x:%02x:%02x:%02x",
nic->mac[0],
nic->mac[1], nic->mac[2],
On Tue, Mar 06, 2012 at 11:04:13AM +0000, Andrew Cooper wrote:> On 06/03/12 10:13, Jan Beulich wrote: > > For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider > > the following changesets from -unstable for backporting:And also these: 24140 tools: xend: tolerate empty state/*.xml 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only) 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h 23225 x86: make the pv-only e820 array be dynamic. 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough 23428 libxl: Add ''e820_host'' option to config file. 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate. 24013 x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercall which I''ve back-ported to 4.1 (please see attachments) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 24/03/2012 18:27, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:> On Tue, Mar 06, 2012 at 11:04:13AM +0000, Andrew Cooper wrote: >> On 06/03/12 10:13, Jan Beulich wrote: >>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >>> the following changesets from -unstable for backporting: > > And also these: > 24140 tools: xend: tolerate empty state/*.xml > 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 > only) > 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h > 23225 x86: make the pv-only e820 array be dynamic. > 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough > 23428 libxl: Add ''e820_host'' option to config file. > 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as > appropriate. > 24013 x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercallApplied 23225 and 24013. The other, toolstack-related, patches I will leave for a tools maintainer to ack or apply. -- Keir> which I''ve back-ported to 4.1 (please see attachments) >
On Thu, Mar 29, 2012 at 5:22 PM, Keir Fraser <keir@xen.org> wrote:> On 24/03/2012 18:27, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote: > >> On Tue, Mar 06, 2012 at 11:04:13AM +0000, Andrew Cooper wrote: >>> On 06/03/12 10:13, Jan Beulich wrote: >>>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >>>> the following changesets from -unstable for backporting: >> >> And also these: >> 24140 tools: xend: tolerate empty state/*.xml >> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 >> only) >> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h >> 23225 x86: make the pv-only e820 array be dynamic. >> 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough >> 23428 libxl: Add ''e820_host'' option to config file. >> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as >> appropriate. >> 24013 x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercall > > Applied 23225 and 24013. The other, toolstack-related, patches I will leave > for a tools maintainer to ack or apply.With the two backport patches committed in xen-4.1-testing (changeset 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU and stuck for couple minutes with high load average and lastly crash the server. Please consider to revert these two commits as I am not sure which one is responsible for such crash. # top -c top - 19:30:54 up 6 min, 4 users, load average: 9.16, 4.34, 1.76 Tasks: 134 total, 4 running, 130 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 98.8%id, 0.2%wa, 0.0%hi, 0.0%si, 0.6%st Mem: 355216k total, 179132k used, 176084k free, 14580k buffers Swap: 2120568k total, 0k used, 2120568k free, 43896k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2856 root 20 0 31832 1416 1008 R 99.0 0.4 5:52.98 xl create /etc/xen/example-hvm-domU.cfg 1 root 20 0 19368 1512 1220 S 0.0 0.4 0:00.35 /sbin/init Thanks. Kindest regards, Giam Teck Choon> > -- Keir > >> which I''ve back-ported to 4.1 (please see attachments) >> > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Thu, Mar 29, 2012 at 7:32 PM, Teck Choon Giam <giamteckchoon@gmail.com> wrote:> On Thu, Mar 29, 2012 at 5:22 PM, Keir Fraser <keir@xen.org> wrote: >> On 24/03/2012 18:27, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote: >> >>> On Tue, Mar 06, 2012 at 11:04:13AM +0000, Andrew Cooper wrote: >>>> On 06/03/12 10:13, Jan Beulich wrote: >>>>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >>>>> the following changesets from -unstable for backporting: >>> >>> And also these: >>> 24140 tools: xend: tolerate empty state/*.xml >>> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 >>> only) >>> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h >>> 23225 x86: make the pv-only e820 array be dynamic. >>> 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough >>> 23428 libxl: Add ''e820_host'' option to config file. >>> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as >>> appropriate. >>> 24013 x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercall >> >> Applied 23225 and 24013. The other, toolstack-related, patches I will leave >> for a tools maintainer to ack or apply. > > With the two backport patches committed in xen-4.1-testing (changeset > 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU and > stuck for couple minutes with high load average and lastly crash the > server. Please consider to revert these two commits as I am not sure > which one is responsible for such crash.Sorry, I shall be more clear about steps to reproduce: xl list is fine as long I didn''t start any domU after reboot. If I xl create hvmdomU.cfg then it will overload the server and xl list will stuck as well... meaning once you issue the first xl create hvmdomU.cfg (starting first domU using xl) then xl list will stuck as well. Last known working changeset for xen-4.1-testing is 23269:d67e4d12723f. Thanks. Kindest regards, Giam Teck Choon> > # top -c > > top - 19:30:54 up 6 min, 4 users, load average: 9.16, 4.34, 1.76 > Tasks: 134 total, 4 running, 130 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 98.8%id, 0.2%wa, 0.0%hi, 0.0%si, 0.6%st > Mem: 355216k total, 179132k used, 176084k free, 14580k buffers > Swap: 2120568k total, 0k used, 2120568k free, 43896k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 2856 root 20 0 31832 1416 1008 R 99.0 0.4 5:52.98 xl create > /etc/xen/example-hvm-domU.cfg > 1 root 20 0 19368 1512 1220 S 0.0 0.4 0:00.35 > /sbin/init > > > Thanks. > > Kindest regards, > Giam Teck Choon > > >> >> -- Keir >> >>> which I''ve back-ported to 4.1 (please see attachments) >>> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel
On Sat, 24 Mar 2012, Konrad Rzeszutek Wilk wrote:> On Tue, Mar 06, 2012 at 11:04:13AM +0000, Andrew Cooper wrote: > > On 06/03/12 10:13, Jan Beulich wrote: > > > For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider > > > the following changesets from -unstable for backporting: > > And also these: > 24140 tools: xend: tolerate empty state/*.xml > 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only) > 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h > 23225 x86: make the pv-only e820 array be dynamic. > 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough > 23428 libxl: Add ''e820_host'' option to config file. > 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate. > 24013 x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercallWhat about: xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 backport appended. --- linux/xen: support pirq_eoi_map The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to be EOI''d without having to issue an hypercall every time. We use PHYSDEVOP_pirq_eoi_gmfn_v2 to map the bitmap, then if we succeed we use pirq_eoi_map to check whether pirqs need eoi. Changes in v2: - explicitly use PHYSDEVOP_pirq_eoi_gmfn_v2 rather than PHYSDEVOP_pirq_eoi_gmfn; - introduce pirq_check_eoi_map, a function to check if a pirq needs an eoi using the map; -rename pirq_needs_eoi into pirq_needs_eoi_flag; - introduce a function pointer called pirq_needs_eoi that is going to be set to the right implementation depending on the availability of PHYSDEVOP_pirq_eoi_gmfn_v2. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/events.c | 26 +++++++++++++++++++++++--- include/xen/interface/physdev.h | 21 +++++++++++++++++++++ 2 files changed, 44 insertions(+), 3 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 6e075cd..cc5fc40 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -37,6 +37,7 @@ #include <asm/idle.h> #include <asm/io_apic.h> #include <asm/sync_bitops.h> +#include <asm/xen/page.h> #include <asm/xen/pci.h> #include <asm/xen/hypercall.h> #include <asm/xen/hypervisor.h> @@ -108,6 +109,8 @@ struct irq_info { #define PIRQ_SHAREABLE (1 << 1) static int *evtchn_to_irq; +static unsigned long *pirq_eoi_map; +static bool (*pirq_needs_eoi)(unsigned irq); static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG], cpu_evtchn_mask); @@ -268,10 +271,14 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn) return ret; } -static bool pirq_needs_eoi(unsigned irq) +static bool pirq_check_eoi_map(unsigned irq) { - struct irq_info *info = info_for_irq(irq); + return test_bit(irq, pirq_eoi_map); +} +static bool pirq_needs_eoi_flag(unsigned irq) +{ + struct irq_info *info = info_for_irq(irq); BUG_ON(info->type != IRQT_PIRQ); return info->u.pirq.flags & PIRQ_NEEDS_EOI; @@ -1693,7 +1700,7 @@ void xen_callback_vector(void) {} void __init xen_init_IRQ(void) { - int i; + int i, rc; evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq), GFP_KERNEL); @@ -1707,6 +1714,8 @@ void __init xen_init_IRQ(void) for (i = 0; i < NR_EVENT_CHANNELS; i++) mask_evtchn(i); + pirq_needs_eoi = pirq_needs_eoi_flag; + if (xen_hvm_domain()) { xen_callback_vector(); native_init_IRQ(); @@ -1714,8 +1723,19 @@ void __init xen_init_IRQ(void) * __acpi_register_gsi can point at the right function */ pci_xen_hvm_init(); } else { + struct physdev_pirq_eoi_gmfn eoi_gmfn; + irq_ctx_init(smp_processor_id()); if (xen_initial_domain()) pci_xen_initial_domain(); + + pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO); + eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map); + rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn); + if (rc != 0) { + free_page((unsigned long) pirq_eoi_map); + pirq_eoi_map = NULL; + } else + pirq_needs_eoi = pirq_check_eoi_map; } } diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h index c1080d9..1775722 100644 --- a/include/xen/interface/physdev.h +++ b/include/xen/interface/physdev.h @@ -39,6 +39,27 @@ struct physdev_eoi { }; /* + * Register a shared page for the hypervisor to indicate whether the guest + * must issue PHYSDEVOP_eoi. The semantics of PHYSDEVOP_eoi change slightly + * once the guest used this function in that the associated event channel + * will automatically get unmasked. The page registered is used as a bit + * array indexed by Xen''s PIRQ value. + */ +#define PHYSDEVOP_pirq_eoi_gmfn_v1 17 +/* + * Register a shared page for the hypervisor to indicate whether the + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to + * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn''t change the semantics of + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by + * Xen''s PIRQ value. + */ +#define PHYSDEVOP_pirq_eoi_gmfn_v2 28 +struct physdev_pirq_eoi_gmfn { + /* IN */ + unsigned long gmfn; +}; + +/* * Query the status of an IRQ line. * @arg == pointer to physdev_irq_status_query structure. */ -- 1.7.2.5
On Thu, Mar 29, 2012 at 07:32:36PM +0800, Teck Choon Giam wrote:> On Thu, Mar 29, 2012 at 5:22 PM, Keir Fraser <keir@xen.org> wrote: > > On 24/03/2012 18:27, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote: > > > >> On Tue, Mar 06, 2012 at 11:04:13AM +0000, Andrew Cooper wrote: > >>> On 06/03/12 10:13, Jan Beulich wrote: > >>>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider > >>>> the following changesets from -unstable for backporting: > >> > >> And also these: > >> 24140 tools: xend: tolerate empty state/*.xml > >> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 > >> only) > >> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h > >> 23225 x86: make the pv-only e820 array be dynamic. > >> 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough > >> 23428 libxl: Add ''e820_host'' option to config file. > >> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as > >> appropriate. > >> 24013 x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercall > > > > Applied 23225 and 24013. The other, toolstack-related, patches I will leave > > for a tools maintainer to ack or apply. >Hey Teck, Thanks for reporting!> With the two backport patches committed in xen-4.1-testing (changeset > 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU andxl list?> stuck for couple minutes with high load average and lastly crash the > server. Please consider to revert these two commits as I am not sure > which one is responsible for such crash.Hm, let me try seeing which one is the culprit. I think it is 23225 as it is suppose to go along the other tool one, but lets double check.> # top -c > > top - 19:30:54 up 6 min, 4 users, load average: 9.16, 4.34, 1.76 > Tasks: 134 total, 4 running, 130 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 98.8%id, 0.2%wa, 0.0%hi, 0.0%si, 0.6%st > Mem: 355216k total, 179132k used, 176084k free, 14580k buffers > Swap: 2120568k total, 0k used, 2120568k free, 43896k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 2856 root 20 0 31832 1416 1008 R 99.0 0.4 5:52.98 xl create > /etc/xen/example-hvm-domU.cfg > 1 root 20 0 19368 1512 1220 S 0.0 0.4 0:00.35 > /sbin/init > > > Thanks. > > Kindest regards, > Giam Teck Choon > > > > > > -- Keir > > > >> which I''ve back-ported to 4.1 (please see attachments) > >> > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel
On Thu, Mar 29, 2012 at 11:11 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Thu, Mar 29, 2012 at 07:32:36PM +0800, Teck Choon Giam wrote: >> On Thu, Mar 29, 2012 at 5:22 PM, Keir Fraser <keir@xen.org> wrote: >> > On 24/03/2012 18:27, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote: >> > >> >> On Tue, Mar 06, 2012 at 11:04:13AM +0000, Andrew Cooper wrote: >> >>> On 06/03/12 10:13, Jan Beulich wrote: >> >>>> For a (hopefully soon) upcoming 4.1.3 and 4.0.4, may I ask to consider >> >>>> the following changesets from -unstable for backporting: >> >> >> >> And also these: >> >> 24140 tools: xend: tolerate empty state/*.xml >> >> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 >> >> only) >> >> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h >> >> 23225 x86: make the pv-only e820 array be dynamic. >> >> 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough >> >> 23428 libxl: Add ''e820_host'' option to config file. >> >> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as >> >> appropriate. >> >> 24013 x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercall >> > >> > Applied 23225 and 24013. The other, toolstack-related, patches I will leave >> > for a tools maintainer to ack or apply. >> > Hey Teck, > > Thanks for reporting! > >> With the two backport patches committed in xen-4.1-testing (changeset >> 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU and > > xl list?After a reboot with no domU running, xl list is fine but if I start a hvm domU will be stuck and caused high load then open another ssh terminal to issue xl list will stuck as well.>> stuck for couple minutes with high load average and lastly crash the >> server. Please consider to revert these two commits as I am not sure >> which one is responsible for such crash. > > Hm, let me try seeing which one is the culprit. I think it is > 23225 as it is suppose to go along the other tool one, but lets double check.I actually tested with the list of patches you posted previously as well and same issue. Thanks. Kindest regards, Giam Teck Choon> >> # top -c >> >> top - 19:30:54 up 6 min, 4 users, load average: 9.16, 4.34, 1.76 >> Tasks: 134 total, 4 running, 130 sleeping, 0 stopped, 0 zombie >> Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 98.8%id, 0.2%wa, 0.0%hi, 0.0%si, 0.6%st >> Mem: 355216k total, 179132k used, 176084k free, 14580k buffers >> Swap: 2120568k total, 0k used, 2120568k free, 43896k cached >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 2856 root 20 0 31832 1416 1008 R 99.0 0.4 5:52.98 xl create >> /etc/xen/example-hvm-domU.cfg >> 1 root 20 0 19368 1512 1220 S 0.0 0.4 0:00.35 >> /sbin/init >> >> >> Thanks. >> >> Kindest regards, >> Giam Teck Choon >> >> >> > >> > -- Keir >> > >> >> which I''ve back-ported to 4.1 (please see attachments) >> >> >> > >> > >> > >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@lists.xen.org >> > http://lists.xen.org/xen-devel
>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> 03/29/12 1:54 PM >>> >What about: > >xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 > >backport appended. > >--- > >linux/xen: support pirq_eoi_mapAs the title says, this is a Linux patch that you provided, yet talk is about Xen backports here. Jan
> >> > Applied 23225 and 24013. The other, toolstack-related, patches I will leave > >> > for a tools maintainer to ack or apply. > >> > > Hey Teck, > > > > Thanks for reporting! > > > >> With the two backport patches committed in xen-4.1-testing (changeset > >> 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU and > > > > xl list? > > After a reboot with no domU running, xl list is fine but if I start a > hvm domU will be stuck and caused high load then open another ssh > terminal to issue xl list will stuck as well.This fix fixes it for me: diff -r 13741fd6253b xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Thu Mar 29 10:20:58 2012 +0100 +++ b/xen/arch/x86/domain.c Thu Mar 29 11:44:54 2012 -0400 @@ -558,9 +558,9 @@ int arch_domain_create(struct domain *d, d->arch.is_32bit_pv = d->arch.has_32bit_shinfo (CONFIG_PAGING_LEVELS != 4); - spin_lock_init(&d->arch.e820_lock); } + spin_lock_init(&d->arch.e820_lock); memset(d->arch.cpuids, 0, sizeof(d->arch.cpuids)); for ( i = 0; i < MAX_CPUID_INPUT; i++ ) { @@ -605,8 +605,8 @@ void arch_domain_destroy(struct domain * if ( is_hvm_domain(d) ) hvm_domain_destroy(d); - else - xfree(d->arch.e820); + + xfree(d->arch.e820); vmce_destroy_msr(d); free_domain_pirqs(d); The issue is that upstream we have two ''domain structs'' - one for PV and one for HVM. In 4.1 it is just ''arch_domain'' and the calls to create the guests are going through the same interface (at least using xl, with xm they are seperate). And I only initialized the spinlock in the PV case, but not in the HVM case. This fix to the backport resolves the problem. Keir, please apply this to my botched back-port of 23225.
On Thu, Mar 29, 2012 at 11:56 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:>> >> > Applied 23225 and 24013. The other, toolstack-related, patches I will leave >> >> > for a tools maintainer to ack or apply. >> >> >> > Hey Teck, >> > >> > Thanks for reporting! >> > >> >> With the two backport patches committed in xen-4.1-testing (changeset >> >> 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU and >> > >> > xl list? >> >> After a reboot with no domU running, xl list is fine but if I start a >> hvm domU will be stuck and caused high load then open another ssh >> terminal to issue xl list will stuck as well. > > This fix fixes it for me: > > diff -r 13741fd6253b xen/arch/x86/domain.c > --- a/xen/arch/x86/domain.c Thu Mar 29 10:20:58 2012 +0100 > +++ b/xen/arch/x86/domain.c Thu Mar 29 11:44:54 2012 -0400 > @@ -558,9 +558,9 @@ int arch_domain_create(struct domain *d, > d->arch.is_32bit_pv = d->arch.has_32bit_shinfo > (CONFIG_PAGING_LEVELS != 4); > > - spin_lock_init(&d->arch.e820_lock); > } > > + spin_lock_init(&d->arch.e820_lock); > memset(d->arch.cpuids, 0, sizeof(d->arch.cpuids)); > for ( i = 0; i < MAX_CPUID_INPUT; i++ ) > { > @@ -605,8 +605,8 @@ void arch_domain_destroy(struct domain * > > if ( is_hvm_domain(d) ) > hvm_domain_destroy(d); > - else > - xfree(d->arch.e820); > + > + xfree(d->arch.e820); > > vmce_destroy_msr(d); > free_domain_pirqs(d); > > > The issue is that upstream we have two ''domain structs'' - one for PV and > one for HVM. In 4.1 it is just ''arch_domain'' and the calls to create > the guests are going through the same interface (at least using xl, with > xm they are seperate). And I only initialized the spinlock in the PV case, > but not in the HVM case. This fix to the backport resolves the problem.Thanks for your fast and prompt fix ;) I am compiling with the fix patch you provided on top of xen-4.1-testing changeset 23271:13741fd6253b. Will test and report back if you are interested ;) Kindest regards, Giam Teck Choon> > Keir, please apply this to my botched back-port of 23225.
On Fri, Mar 30, 2012 at 12:20:05AM +0800, Teck Choon Giam wrote:> On Thu, Mar 29, 2012 at 11:56 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > >> >> > Applied 23225 and 24013. The other, toolstack-related, patches I will leave > >> >> > for a tools maintainer to ack or apply. > >> >> > >> > Hey Teck, > >> > > >> > Thanks for reporting! > >> > > >> >> With the two backport patches committed in xen-4.1-testing (changeset > >> >> 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU and > >> > > >> > xl list? > >> > >> After a reboot with no domU running, xl list is fine but if I start a > >> hvm domU will be stuck and caused high load then open another ssh > >> terminal to issue xl list will stuck as well. > > > > This fix fixes it for me: > > > > diff -r 13741fd6253b xen/arch/x86/domain.c > > --- a/xen/arch/x86/domain.c Thu Mar 29 10:20:58 2012 +0100 > > +++ b/xen/arch/x86/domain.c Thu Mar 29 11:44:54 2012 -0400 > > @@ -558,9 +558,9 @@ int arch_domain_create(struct domain *d, > > d->arch.is_32bit_pv = d->arch.has_32bit_shinfo > > (CONFIG_PAGING_LEVELS != 4); > > > > - spin_lock_init(&d->arch.e820_lock); > > } > > > > + spin_lock_init(&d->arch.e820_lock); > > memset(d->arch.cpuids, 0, sizeof(d->arch.cpuids)); > > for ( i = 0; i < MAX_CPUID_INPUT; i++ ) > > { > > @@ -605,8 +605,8 @@ void arch_domain_destroy(struct domain * > > > > if ( is_hvm_domain(d) ) > > hvm_domain_destroy(d); > > - else > > - xfree(d->arch.e820); > > + > > + xfree(d->arch.e820); > > > > vmce_destroy_msr(d); > > free_domain_pirqs(d); > > > > > > The issue is that upstream we have two ''domain structs'' - one for PV and > > one for HVM. In 4.1 it is just ''arch_domain'' and the calls to create > > the guests are going through the same interface (at least using xl, with > > xm they are seperate). And I only initialized the spinlock in the PV case, > > but not in the HVM case. This fix to the backport resolves the problem. > > Thanks for your fast and prompt fix ;) > > I am compiling with the fix patch you provided on top of > xen-4.1-testing changeset 23271:13741fd6253b. Will test and report > back if you are interested ;)Yes please! If you find other issues, please report them immediately! Thanks again for doing this.
On Fri, Mar 30, 2012 at 12:23 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Fri, Mar 30, 2012 at 12:20:05AM +0800, Teck Choon Giam wrote: >> On Thu, Mar 29, 2012 at 11:56 PM, Konrad Rzeszutek Wilk >> <konrad.wilk@oracle.com> wrote: >> >> >> > Applied 23225 and 24013. The other, toolstack-related, patches I will leave >> >> >> > for a tools maintainer to ack or apply. >> >> >> >> >> > Hey Teck, >> >> > >> >> > Thanks for reporting! >> >> > >> >> >> With the two backport patches committed in xen-4.1-testing (changeset >> >> >> 23271:13741fd6253b), xl list or xl create domU will cause 100% CPU and >> >> > >> >> > xl list? >> >> >> >> After a reboot with no domU running, xl list is fine but if I start a >> >> hvm domU will be stuck and caused high load then open another ssh >> >> terminal to issue xl list will stuck as well. >> > >> > This fix fixes it for me: >> > >> > diff -r 13741fd6253b xen/arch/x86/domain.c >> > --- a/xen/arch/x86/domain.c Thu Mar 29 10:20:58 2012 +0100 >> > +++ b/xen/arch/x86/domain.c Thu Mar 29 11:44:54 2012 -0400 >> > @@ -558,9 +558,9 @@ int arch_domain_create(struct domain *d, >> > d->arch.is_32bit_pv = d->arch.has_32bit_shinfo >> > (CONFIG_PAGING_LEVELS != 4); >> > >> > - spin_lock_init(&d->arch.e820_lock); >> > } >> > >> > + spin_lock_init(&d->arch.e820_lock); >> > memset(d->arch.cpuids, 0, sizeof(d->arch.cpuids)); >> > for ( i = 0; i < MAX_CPUID_INPUT; i++ ) >> > { >> > @@ -605,8 +605,8 @@ void arch_domain_destroy(struct domain * >> > >> > if ( is_hvm_domain(d) ) >> > hvm_domain_destroy(d); >> > - else >> > - xfree(d->arch.e820); >> > + >> > + xfree(d->arch.e820); >> > >> > vmce_destroy_msr(d); >> > free_domain_pirqs(d); >> > >> > >> > The issue is that upstream we have two ''domain structs'' - one for PV and >> > one for HVM. In 4.1 it is just ''arch_domain'' and the calls to create >> > the guests are going through the same interface (at least using xl, with >> > xm they are seperate). And I only initialized the spinlock in the PV case, >> > but not in the HVM case. This fix to the backport resolves the problem. >> >> Thanks for your fast and prompt fix ;) >> >> I am compiling with the fix patch you provided on top of >> xen-4.1-testing changeset 23271:13741fd6253b. Will test and report >> back if you are interested ;) > > Yes please! If you find other issues, please report them immediately! Thanks > again for doing this.Thanks and it works!
On Thu, 29 Mar 2012, Jan Beulich wrote:> >>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> 03/29/12 1:54 PM >>> > >What about: > > > >xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 > > > >backport appended. > > > >--- > > > >linux/xen: support pirq_eoi_map > > As the title says, this is a Linux patch that you provided, yet talk is about > Xen backports here.Oops, I have appended the wrong patch. Now I am appending the right one. Please note that the patch bumps __XEN_LATEST_INTERFACE_VERSION__ but it is not a requirement to get Linux kernels to work correctly with it. I would welcome opinions on whether we would need to backport that change too or not. --- xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi. In order to improve the interface this patch: - renames PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1; - introduces PHYSDEVOP_pirq_eoi_gmfn_v2, that is like PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn''t modify the behaviour of another hypercall; - bump __XEN_LATEST_INTERFACE_VERSION__; - #define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1 or PHYSDEVOP_pirq_eoi_gmfn_v2 depending on the __XEN_INTERFACE_VERSION. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- xen/arch/ia64/xen/domain.c | 1 + xen/arch/ia64/xen/hypercall.c | 7 +++++-- xen/arch/x86/domain.c | 1 + xen/arch/x86/physdev.c | 7 +++++-- xen/include/asm-ia64/domain.h | 3 +++ xen/include/asm-x86/domain.h | 3 +++ xen/include/public/physdev.h | 16 +++++++++++++++- xen/include/public/xen-compat.h | 2 +- 8 files changed, 34 insertions(+), 6 deletions(-) diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c index 271a744..7dd96bf 100644 --- a/xen/arch/ia64/xen/domain.c +++ b/xen/arch/ia64/xen/domain.c @@ -1729,6 +1729,7 @@ int domain_relinquish_resources(struct domain *d) if (d->arch.pirq_eoi_map != NULL) { put_page(virt_to_page(d->arch.pirq_eoi_map)); d->arch.pirq_eoi_map = NULL; + d->arch.auto_unmask = 0; } /* Tear down shadow mode stuff. */ diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c index 6ea15c2..22b06ec 100644 --- a/xen/arch/ia64/xen/hypercall.c +++ b/xen/arch/ia64/xen/hypercall.c @@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq) { if ( pirq < 0 || pirq >= NR_IRQS ) return -EINVAL; - if ( d->arch.pirq_eoi_map ) + if ( d->arch.auto_unmask ) { evtchn_unmask(d->pirq_to_evtchn[pirq]); return pirq_guest_eoi(d, pirq); } @@ -504,7 +504,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) break; } - case PHYSDEVOP_pirq_eoi_gmfn: { + case PHYSDEVOP_pirq_eoi_gmfn_v1: + case PHYSDEVOP_pirq_eoi_gmfn_v2: { struct physdev_pirq_eoi_gmfn info; unsigned long mfn; @@ -527,6 +528,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) } current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn); + if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 ) + current->domain->arch.auto_unmask = 1; ret = 0; break; } diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index d432eb8..8472e30 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1935,6 +1935,7 @@ int domain_relinquish_resources(struct domain *d) unmap_domain_page_global(d->arch.pirq_eoi_map); put_page_and_type(mfn_to_page(d->arch.pirq_eoi_map_mfn)); d->arch.pirq_eoi_map = NULL; + d->arch.auto_unmask = 0; } d->arch.relmem = RELMEM_xen; diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c index 3454c03..53c2461 100644 --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -264,7 +264,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) ret = -EINVAL; if ( eoi.irq >= v->domain->nr_pirqs ) break; - if ( v->domain->arch.pirq_eoi_map ) + if ( v->domain->arch.auto_unmask ) evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]); if ( !is_hvm_domain(v->domain) || domain_pirq_to_emuirq(v->domain, eoi.irq) == IRQ_PT ) @@ -274,7 +274,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) break; } - case PHYSDEVOP_pirq_eoi_gmfn: { + case PHYSDEVOP_pirq_eoi_gmfn_v2: + case PHYSDEVOP_pirq_eoi_gmfn_v1: { struct physdev_pirq_eoi_gmfn info; unsigned long mfn; @@ -304,6 +305,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) ret = -ENOSPC; break; } + if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 ) + v->domain->arch.auto_unmask = 1; ret = 0; break; diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h index 14064ce..fc7b34f 100644 --- a/xen/include/asm-ia64/domain.h +++ b/xen/include/asm-ia64/domain.h @@ -182,6 +182,9 @@ struct arch_domain { /* Shared page for notifying that explicit PIRQ EOI is required. */ unsigned long *pirq_eoi_map; unsigned long pirq_eoi_map_mfn; + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically + * unmask the event channel */ + bool_t auto_unmask; /* Address of efi_runtime_services_t (placed in domain memory) */ void *efi_runtime; diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h index 8056559..75f2540 100644 --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -268,6 +268,9 @@ struct arch_domain /* Shared page for notifying that explicit PIRQ EOI is required. */ unsigned long *pirq_eoi_map; unsigned long pirq_eoi_map_mfn; + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically + * unmask the event channel */ + bool_t auto_unmask; /* Pseudophysical e820 map (XENMEM_memory_map). */ struct e820entry e820[3]; diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h index 82602ca..2e0ee53 100644 --- a/xen/include/public/physdev.h +++ b/xen/include/public/physdev.h @@ -49,7 +49,15 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t); * will automatically get unmasked. The page registered is used as a bit * array indexed by Xen''s PIRQ value. */ -#define PHYSDEVOP_pirq_eoi_gmfn 17 +#define PHYSDEVOP_pirq_eoi_gmfn_v1 17 +/* + * Register a shared page for the hypervisor to indicate whether the + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to + * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn''t change the semantics of + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by + * Xen''s PIRQ value. + */ +#define PHYSDEVOP_pirq_eoi_gmfn_v2 28 struct physdev_pirq_eoi_gmfn { /* IN */ xen_pfn_t gmfn; @@ -276,6 +284,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_get_free_pirq_t); #define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi #define PHYSDEVOP_IRQ_SHARED XENIRQSTAT_shared +#if __XEN_INTERFACE_VERSION < 0x00040200 +#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1 +#else +#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2 +#endif + #endif /* __XEN_PUBLIC_PHYSDEV_H__ */ /* diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h index 2e38003..d8c55bf 100644 --- a/xen/include/public/xen-compat.h +++ b/xen/include/public/xen-compat.h @@ -27,7 +27,7 @@ #ifndef __XEN_PUBLIC_XEN_COMPAT_H__ #define __XEN_PUBLIC_XEN_COMPAT_H__ -#define __XEN_LATEST_INTERFACE_VERSION__ 0x0003020a +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200 #if defined(__XEN__) || defined(__XEN_TOOLS__) /* Xen is built with matching headers and implements the latest interface. */ -- 1.7.2.5
On 29/03/2012 18:06, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com> wrote:> On Thu, 29 Mar 2012, Jan Beulich wrote: >>>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> 03/29/12 1:54 PM >>> >>> What about: >>> >>> xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 >>> >>> backport appended. >>> >>> --- >>> >>> linux/xen: support pirq_eoi_map >> >> As the title says, this is a Linux patch that you provided, yet talk is about >> Xen backports here. > > Oops, I have appended the wrong patch. Now I am appending the right one. > > Please note that the patch bumps __XEN_LATEST_INTERFACE_VERSION__ but it > is not a requirement to get Linux kernels to work correctly with it. > I would welcome opinions on whether we would need to backport that > change too or not.Let''s not. Please re-spin the patch to unconditionally define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1, and don''t touch __XEN_LATEST_INTERFACE_VERSION__. Thanks, Keir> > --- > > xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 > > PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi. > In order to improve the interface this patch: > > - renames PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1; > > - introduces PHYSDEVOP_pirq_eoi_gmfn_v2, that is like > PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn''t modify the behaviour of > another hypercall; > > - bump __XEN_LATEST_INTERFACE_VERSION__; > > - #define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1 or > PHYSDEVOP_pirq_eoi_gmfn_v2 depending on the __XEN_INTERFACE_VERSION. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > --- > xen/arch/ia64/xen/domain.c | 1 + > xen/arch/ia64/xen/hypercall.c | 7 +++++-- > xen/arch/x86/domain.c | 1 + > xen/arch/x86/physdev.c | 7 +++++-- > xen/include/asm-ia64/domain.h | 3 +++ > xen/include/asm-x86/domain.h | 3 +++ > xen/include/public/physdev.h | 16 +++++++++++++++- > xen/include/public/xen-compat.h | 2 +- > 8 files changed, 34 insertions(+), 6 deletions(-) > > diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c > index 271a744..7dd96bf 100644 > --- a/xen/arch/ia64/xen/domain.c > +++ b/xen/arch/ia64/xen/domain.c > @@ -1729,6 +1729,7 @@ int domain_relinquish_resources(struct domain *d) > if (d->arch.pirq_eoi_map != NULL) { > put_page(virt_to_page(d->arch.pirq_eoi_map)); > d->arch.pirq_eoi_map = NULL; > + d->arch.auto_unmask = 0; > } > > /* Tear down shadow mode stuff. */ > diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c > index 6ea15c2..22b06ec 100644 > --- a/xen/arch/ia64/xen/hypercall.c > +++ b/xen/arch/ia64/xen/hypercall.c > @@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq) > { > if ( pirq < 0 || pirq >= NR_IRQS ) > return -EINVAL; > - if ( d->arch.pirq_eoi_map ) > + if ( d->arch.auto_unmask ) { > evtchn_unmask(d->pirq_to_evtchn[pirq]); > return pirq_guest_eoi(d, pirq); > } > @@ -504,7 +504,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) > break; > } > > - case PHYSDEVOP_pirq_eoi_gmfn: { > + case PHYSDEVOP_pirq_eoi_gmfn_v1: > + case PHYSDEVOP_pirq_eoi_gmfn_v2: { > struct physdev_pirq_eoi_gmfn info; > unsigned long mfn; > > @@ -527,6 +528,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) > } > > current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn); > + if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 ) > + current->domain->arch.auto_unmask = 1; > ret = 0; > break; > } > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index d432eb8..8472e30 100644 > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1935,6 +1935,7 @@ int domain_relinquish_resources(struct domain *d) > unmap_domain_page_global(d->arch.pirq_eoi_map); > put_page_and_type(mfn_to_page(d->arch.pirq_eoi_map_mfn)); > d->arch.pirq_eoi_map = NULL; > + d->arch.auto_unmask = 0; > } > > d->arch.relmem = RELMEM_xen; > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c > index 3454c03..53c2461 100644 > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -264,7 +264,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) > ret = -EINVAL; > if ( eoi.irq >= v->domain->nr_pirqs ) > break; > - if ( v->domain->arch.pirq_eoi_map ) > + if ( v->domain->arch.auto_unmask ) > evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]); > if ( !is_hvm_domain(v->domain) || > domain_pirq_to_emuirq(v->domain, eoi.irq) == IRQ_PT ) > @@ -274,7 +274,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) > break; > } > > - case PHYSDEVOP_pirq_eoi_gmfn: { > + case PHYSDEVOP_pirq_eoi_gmfn_v2: > + case PHYSDEVOP_pirq_eoi_gmfn_v1: { > struct physdev_pirq_eoi_gmfn info; > unsigned long mfn; > > @@ -304,6 +305,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) > ret = -ENOSPC; > break; > } > + if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 ) > + v->domain->arch.auto_unmask = 1; > > ret = 0; > break; > diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h > index 14064ce..fc7b34f 100644 > --- a/xen/include/asm-ia64/domain.h > +++ b/xen/include/asm-ia64/domain.h > @@ -182,6 +182,9 @@ struct arch_domain { > /* Shared page for notifying that explicit PIRQ EOI is required. */ > unsigned long *pirq_eoi_map; > unsigned long pirq_eoi_map_mfn; > + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically > + * unmask the event channel */ > + bool_t auto_unmask; > > /* Address of efi_runtime_services_t (placed in domain memory) */ > void *efi_runtime; > diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h > index 8056559..75f2540 100644 > --- a/xen/include/asm-x86/domain.h > +++ b/xen/include/asm-x86/domain.h > @@ -268,6 +268,9 @@ struct arch_domain > /* Shared page for notifying that explicit PIRQ EOI is required. */ > unsigned long *pirq_eoi_map; > unsigned long pirq_eoi_map_mfn; > + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically > + * unmask the event channel */ > + bool_t auto_unmask; > > /* Pseudophysical e820 map (XENMEM_memory_map). */ > struct e820entry e820[3]; > diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h > index 82602ca..2e0ee53 100644 > --- a/xen/include/public/physdev.h > +++ b/xen/include/public/physdev.h > @@ -49,7 +49,15 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t); > * will automatically get unmasked. The page registered is used as a bit > * array indexed by Xen''s PIRQ value. > */ > -#define PHYSDEVOP_pirq_eoi_gmfn 17 > +#define PHYSDEVOP_pirq_eoi_gmfn_v1 17 > +/* > + * Register a shared page for the hypervisor to indicate whether the > + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to > + * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn''t change the semantics of > + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by > + * Xen''s PIRQ value. > + */ > +#define PHYSDEVOP_pirq_eoi_gmfn_v2 28 > struct physdev_pirq_eoi_gmfn { > /* IN */ > xen_pfn_t gmfn; > @@ -276,6 +284,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_get_free_pirq_t); > #define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi > #define PHYSDEVOP_IRQ_SHARED XENIRQSTAT_shared > > +#if __XEN_INTERFACE_VERSION < 0x00040200 > +#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1 > +#else > +#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2 > +#endif > + > #endif /* __XEN_PUBLIC_PHYSDEV_H__ */ > > /* > diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h > index 2e38003..d8c55bf 100644 > --- a/xen/include/public/xen-compat.h > +++ b/xen/include/public/xen-compat.h > @@ -27,7 +27,7 @@ > #ifndef __XEN_PUBLIC_XEN_COMPAT_H__ > #define __XEN_PUBLIC_XEN_COMPAT_H__ > > -#define __XEN_LATEST_INTERFACE_VERSION__ 0x0003020a > +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200 > > #if defined(__XEN__) || defined(__XEN_TOOLS__) > /* Xen is built with matching headers and implements the latest interface. */
On Fri, 30 Mar 2012, Keir Fraser wrote:> On 29/03/2012 18:06, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com> > wrote: > > > On Thu, 29 Mar 2012, Jan Beulich wrote: > >>>>> Stefano Stabellini <stefano.stabellini@eu.citrix.com> 03/29/12 1:54 PM >>> > >>> What about: > >>> > >>> xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 > >>> > >>> backport appended. > >>> > >>> --- > >>> > >>> linux/xen: support pirq_eoi_map > >> > >> As the title says, this is a Linux patch that you provided, yet talk is about > >> Xen backports here. > > > > Oops, I have appended the wrong patch. Now I am appending the right one. > > > > Please note that the patch bumps __XEN_LATEST_INTERFACE_VERSION__ but it > > is not a requirement to get Linux kernels to work correctly with it. > > I would welcome opinions on whether we would need to backport that > > change too or not. > > Let''s not. Please re-spin the patch to unconditionally define > PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1, and don''t touch > __XEN_LATEST_INTERFACE_VERSION__.Agreed, below and attached the updated patch. --- xen: introduce PHYSDEVOP_pirq_eoi_gmfn_v2 PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi. In order to improve the interface this patch: - renames PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1; - introduces PHYSDEVOP_pirq_eoi_gmfn_v2, that is like PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn''t modify the behaviour of another hypercall; - #define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- xen/arch/ia64/xen/domain.c | 1 + xen/arch/ia64/xen/hypercall.c | 7 +++++-- xen/arch/x86/domain.c | 1 + xen/arch/x86/physdev.c | 7 +++++-- xen/include/asm-ia64/domain.h | 3 +++ xen/include/asm-x86/domain.h | 3 +++ xen/include/public/physdev.h | 12 +++++++++++- 7 files changed, 29 insertions(+), 5 deletions(-) diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c index 271a744..7dd96bf 100644 --- a/xen/arch/ia64/xen/domain.c +++ b/xen/arch/ia64/xen/domain.c @@ -1729,6 +1729,7 @@ int domain_relinquish_resources(struct domain *d) if (d->arch.pirq_eoi_map != NULL) { put_page(virt_to_page(d->arch.pirq_eoi_map)); d->arch.pirq_eoi_map = NULL; + d->arch.auto_unmask = 0; } /* Tear down shadow mode stuff. */ diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c index 6ea15c2..22b06ec 100644 --- a/xen/arch/ia64/xen/hypercall.c +++ b/xen/arch/ia64/xen/hypercall.c @@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq) { if ( pirq < 0 || pirq >= NR_IRQS ) return -EINVAL; - if ( d->arch.pirq_eoi_map ) + if ( d->arch.auto_unmask ) { evtchn_unmask(d->pirq_to_evtchn[pirq]); return pirq_guest_eoi(d, pirq); } @@ -504,7 +504,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) break; } - case PHYSDEVOP_pirq_eoi_gmfn: { + case PHYSDEVOP_pirq_eoi_gmfn_v1: + case PHYSDEVOP_pirq_eoi_gmfn_v2: { struct physdev_pirq_eoi_gmfn info; unsigned long mfn; @@ -527,6 +528,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) } current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn); + if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 ) + current->domain->arch.auto_unmask = 1; ret = 0; break; } diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index d432eb8..8472e30 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1935,6 +1935,7 @@ int domain_relinquish_resources(struct domain *d) unmap_domain_page_global(d->arch.pirq_eoi_map); put_page_and_type(mfn_to_page(d->arch.pirq_eoi_map_mfn)); d->arch.pirq_eoi_map = NULL; + d->arch.auto_unmask = 0; } d->arch.relmem = RELMEM_xen; diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c index 3454c03..53c2461 100644 --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -264,7 +264,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) ret = -EINVAL; if ( eoi.irq >= v->domain->nr_pirqs ) break; - if ( v->domain->arch.pirq_eoi_map ) + if ( v->domain->arch.auto_unmask ) evtchn_unmask(v->domain->pirq_to_evtchn[eoi.irq]); if ( !is_hvm_domain(v->domain) || domain_pirq_to_emuirq(v->domain, eoi.irq) == IRQ_PT ) @@ -274,7 +274,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) break; } - case PHYSDEVOP_pirq_eoi_gmfn: { + case PHYSDEVOP_pirq_eoi_gmfn_v2: + case PHYSDEVOP_pirq_eoi_gmfn_v1: { struct physdev_pirq_eoi_gmfn info; unsigned long mfn; @@ -304,6 +305,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) ret = -ENOSPC; break; } + if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 ) + v->domain->arch.auto_unmask = 1; ret = 0; break; diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h index 14064ce..fc7b34f 100644 --- a/xen/include/asm-ia64/domain.h +++ b/xen/include/asm-ia64/domain.h @@ -182,6 +182,9 @@ struct arch_domain { /* Shared page for notifying that explicit PIRQ EOI is required. */ unsigned long *pirq_eoi_map; unsigned long pirq_eoi_map_mfn; + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically + * unmask the event channel */ + bool_t auto_unmask; /* Address of efi_runtime_services_t (placed in domain memory) */ void *efi_runtime; diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h index 8056559..75f2540 100644 --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -268,6 +268,9 @@ struct arch_domain /* Shared page for notifying that explicit PIRQ EOI is required. */ unsigned long *pirq_eoi_map; unsigned long pirq_eoi_map_mfn; + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically + * unmask the event channel */ + bool_t auto_unmask; /* Pseudophysical e820 map (XENMEM_memory_map). */ struct e820entry e820[3]; diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h index 82602ca..6f792ee 100644 --- a/xen/include/public/physdev.h +++ b/xen/include/public/physdev.h @@ -49,7 +49,15 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t); * will automatically get unmasked. The page registered is used as a bit * array indexed by Xen''s PIRQ value. */ -#define PHYSDEVOP_pirq_eoi_gmfn 17 +#define PHYSDEVOP_pirq_eoi_gmfn_v1 17 +/* + * Register a shared page for the hypervisor to indicate whether the + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to + * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn''t change the semantics of + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by + * Xen''s PIRQ value. + */ +#define PHYSDEVOP_pirq_eoi_gmfn_v2 28 struct physdev_pirq_eoi_gmfn { /* IN */ xen_pfn_t gmfn; @@ -276,6 +284,8 @@ DEFINE_XEN_GUEST_HANDLE(physdev_get_free_pirq_t); #define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi #define PHYSDEVOP_IRQ_SHARED XENIRQSTAT_shared +#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1 + #endif /* __XEN_PUBLIC_PHYSDEV_H__ */ /* -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Teck Choon Giam writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> libxl: write vifname in xenstore if set.
>
> Simple fix to enable user to specify vif names.
>
> xen-unstable changeset: 24459:caf9753d4cc1
> Backport-requested-by: Roderick Colenbrander
<thunderbird2k@gmail.com>
>
> Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
Marvellous, thanks.
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> And also these:
> 24140 tools: xend: tolerate empty state/*.xml
I have backported this.
> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86,
amd64 only)
> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h
> 23426 libxl: Add support for passing in the host''s E820 for PCI
passthrough
> 23428 libxl: Add ''e820_host'' option to config file.
> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as
appropriate.
I''m not really convinced that these are appropriate for backporting to
a supposedly stable tree.
Thanks,
Ian.
On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] backport requests for 4.x-testing"): >> And also these: >> 24140 tools: xend: tolerate empty state/*.xml > > I have backported this. > >> 23412 libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only) >> 23632 libxc: Squash xc_e820.h (and delete) into xenctrl.h >> 23426 libxl: Add support for passing in the host''s E820 for PCI passthrough >> 23428 libxl: Add ''e820_host'' option to config file. >> 23427 libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate. > > I''m not really convinced that these are appropriate for backporting to > a supposedly stable tree.What about the changeset 25131:6f81f4d79fde? It won''t be able to apply cleanly in xen-4.1-testing though and I can provide the backport version for review if you give an OK? Thanks. Kindest regards, Giam Teck Choon
Teck Choon Giam writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote:
> > I''m not really convinced that these are appropriate for
backporting to
> > a supposedly stable tree.
>
> What about the changeset 25131:6f81f4d79fde? It won''t be able to
> apply cleanly in xen-4.1-testing though and I can provide the backport
> version for review if you give an OK?
I would be happy to consider a backport of 25131, yes. You''ll have to
do some work as 4.1 doesn''t have libxl_defbool_*.
Thanks,
Ian.
On Wed, Apr 4, 2012 at 12:58 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"): >> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >> > I''m not really convinced that these are appropriate for backporting to >> > a supposedly stable tree. >> >> What about the changeset 25131:6f81f4d79fde? It won''t be able to >> apply cleanly in xen-4.1-testing though and I can provide the backport >> version for review if you give an OK? > > I would be happy to consider a backport of 25131, yes. You''ll have to > do some work as 4.1 doesn''t have libxl_defbool_*.Not just libxl_defbool_* but also couple others :p Anyway, here is my backport which I have tested and worked as described in http://lists.xen.org/archives/html/xen-devel/2012-03/msg01452.html For your review and comments please. libxl: support for "rtc_timeoffset" and "localtime" Implement "rtc_timeoffset" and "localtime" options compatible as xm. rtc_timeoffset is the offset between host time and guest time. localtime means to specify whether the emulted RTC appears as UTC or is offset by the host. xen-unstable changeset: 25131:6f81f4d79fde Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com> --- tools/libxl/libxl.idl | 2 ++ tools/libxl/libxl_dom.c | 3 +++ tools/libxl/xl_cmdimpl.c | 13 +++++++++++++ 3 files changed, 18 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl.idl index 377417a..3193506 100644 --- a/tools/libxl/libxl.idl +++ b/tools/libxl/libxl.idl @@ -94,6 +94,8 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("target_memkb", uint32), ("video_memkb", uint32), ("shadow_memkb", uint32), + ("rtc_timeoffset", uint32), + ("localtime", bool), ("disable_migrate", bool), ("kernel", libxl_file_reference), ("cpuid", libxl_cpuid_policy_list), diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index c702cf7..7ab78db 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -76,6 +76,9 @@ int libxl__build_pre(libxl_ctx *ctx, uint32_t domid, if ( info->disable_migrate ) xc_domain_disable_migrate(ctx->xch, domid); + if (info->rtc_timeoffset) + xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset); + if (info->hvm) { unsigned long shadow; shadow = (info->shadow_memkb + 1023) / 1024; diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 2dbced7..74545a5 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -737,6 +737,19 @@ static void parse_config_data(const char *configfile_filename_report, if (!xlu_cfg_get_long(config, "tsc_mode", &l)) b_info->tsc_mode = l; + b_info->rtc_timeoffset = !xlu_cfg_get_long(config, "rtc_timeoffset", &l) ? l : 0; + + b_info->localtime = !xlu_cfg_get_long(config, "localtime", &l) ? l : 0; + if (b_info->localtime) { + time_t t; + struct tm *tm; + + t = time(NULL); + tm = localtime(&t); + + b_info->rtc_timeoffset += tm->tm_gmtoff; + } + if (!xlu_cfg_get_long (config, "videoram", &l)) b_info->video_memkb = l * 1024;> > Thanks, > Ian.Thanks. Kindest regards, Giam Teck Choon
On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com> wrote:> On Wed, Apr 4, 2012 at 12:58 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"): >>> On Tue, Apr 3, 2012 at 11:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >>> > I''m not really convinced that these are appropriate for backporting to >>> > a supposedly stable tree. >>> >>> What about the changeset 25131:6f81f4d79fde? It won''t be able to >>> apply cleanly in xen-4.1-testing though and I can provide the backport >>> version for review if you give an OK? >> >> I would be happy to consider a backport of 25131, yes. You''ll have to >> do some work as 4.1 doesn''t have libxl_defbool_*. > > Not just libxl_defbool_* but also couple others :p > > Anyway, here is my backport which I have tested and worked as > described in http://lists.xen.org/archives/html/xen-devel/2012-03/msg01452.html > For your review and comments please. > > > libxl: support for "rtc_timeoffset" and "localtime" > > Implement "rtc_timeoffset" and "localtime" options compatible as xm. > > rtc_timeoffset is the offset between host time and guest time. > localtime means to specify whether the emulted RTC appears as UTC or is > offset by the host. > > xen-unstable changeset: 25131:6f81f4d79fde > > Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com> > > --- > tools/libxl/libxl.idl | 2 ++ > tools/libxl/libxl_dom.c | 3 +++ > tools/libxl/xl_cmdimpl.c | 13 +++++++++++++ > 3 files changed, 18 insertions(+), 0 deletions(-) > > diff --git a/tools/libxl/libxl.idl b/tools/libxl/libxl.idl > index 377417a..3193506 100644 > --- a/tools/libxl/libxl.idl > +++ b/tools/libxl/libxl.idl > @@ -94,6 +94,8 @@ libxl_domain_build_info = Struct("domain_build_info",[ > ("target_memkb", uint32), > ("video_memkb", uint32), > ("shadow_memkb", uint32), > + ("rtc_timeoffset", uint32), > + ("localtime", bool), > ("disable_migrate", bool), > ("kernel", libxl_file_reference), > ("cpuid", libxl_cpuid_policy_list), > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c > index c702cf7..7ab78db 100644 > --- a/tools/libxl/libxl_dom.c > +++ b/tools/libxl/libxl_dom.c > @@ -76,6 +76,9 @@ int libxl__build_pre(libxl_ctx *ctx, uint32_t domid, > if ( info->disable_migrate ) > xc_domain_disable_migrate(ctx->xch, domid); > > + if (info->rtc_timeoffset) > + xc_domain_set_time_offset(ctx->xch, domid, info->rtc_timeoffset); > + > if (info->hvm) { > unsigned long shadow; > shadow = (info->shadow_memkb + 1023) / 1024; > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c > index 2dbced7..74545a5 100644 > --- a/tools/libxl/xl_cmdimpl.c > +++ b/tools/libxl/xl_cmdimpl.c > @@ -737,6 +737,19 @@ static void parse_config_data(const char > *configfile_filename_report, > if (!xlu_cfg_get_long(config, "tsc_mode", &l)) > b_info->tsc_mode = l; > > + b_info->rtc_timeoffset = !xlu_cfg_get_long(config, > "rtc_timeoffset", &l) ? l : 0;Ops... forgot about coding style... need to be within 80 column... I will roll out another patch to fix this after your review. Sorry :( Thanks. Kindest regards, Giam Teck Choon> + > + b_info->localtime = !xlu_cfg_get_long(config, "localtime", &l) ? l : 0; > + if (b_info->localtime) { > + time_t t; > + struct tm *tm; > + > + t = time(NULL); > + tm = localtime(&t); > + > + b_info->rtc_timeoffset += tm->tm_gmtoff; > + } > + > if (!xlu_cfg_get_long (config, "videoram", &l)) > b_info->video_memkb = l * 1024; > > > >> >> Thanks, >> Ian. > > Thanks. > > Kindest regards, > Giam Teck Choon
Teck Choon Giam writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam
<giamteckchoon@gmail.com> wrot> > For your review and comments
please.
...> > libxl: support for "rtc_timeoffset" and
"localtime"
Thanks, looks good to me.
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Unfortunately...> > + b_info->rtc_timeoffset = !xlu_cfg_get_long(config,
> > "rtc_timeoffset", &l) ? l : 0;
Your email program wrapped it.
> Ops... forgot about coding style... need to be within 80 column... I
> will roll out another patch to fix this after your review. Sorry :(
I think if you fix the coding style you will avoid the bug in your
email program. Alternatively, include the patch as an attachment too.
Ian.
On Wed, Apr 4, 2012 at 6:22 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"): >> On Wed, Apr 4, 2012 at 3:50 AM, Teck Choon Giam <giamteckchoon@gmail.com> wrot> > For your review and comments please. > ... >> > libxl: support for "rtc_timeoffset" and "localtime" > > Thanks, looks good to me. > > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> > > Unfortunately... >> > + b_info->rtc_timeoffset = !xlu_cfg_get_long(config, >> > "rtc_timeoffset", &l) ? l : 0; > > Your email program wrapped it. > >> Ops... forgot about coding style... need to be within 80 column... I >> will roll out another patch to fix this after your review. Sorry :( > > I think if you fix the coding style you will avoid the bug in your > email program. Alternatively, include the patch as an attachment too.Yes, I know gmail wrapped it as it is longer than 80 in length. Attached is the fix patch.> > Ian.Thanks Ian for taking time to review ;) Kindest regards, Giam Teck Choon _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Teck Choon Giam writes ("Re: [Xen-devel] backport requests for
4.x-testing"):> On Wed, Apr 4, 2012 at 6:22 PM, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote:
> > I think if you fix the coding style you will avoid the bug in your
> > email program. Alternatively, include the patch as an attachment too.
>
> Yes, I know gmail wrapped it as it is longer than 80 in length.
> Attached is the fix patch.
Thanks, applied.
Ian.