backport requests for 4.x-testing

backport requests for 4.x-testing

[Jan Beulich]

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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

Re: backport requests for 4.x-testing

[Andrew Cooper]

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

Re: backport requests for 4.x-testing

[Roderick Colenbrander]

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Teck Choon Giam]

Sorry, one more cs 24593 ?

Thanks.

Kindest regards,
Giam Teck Choon

Re: backport requests for 4.x-testing

[Ian Jackson]

Teck Choon Giam writes ("Re: [Xen-devel] backport requests for 4.x-testing"):
> Sorry, one more cs 24593 ?

That one looks reasonable.  Done.

Ian.

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Teck Choon Giam]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

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

[-- Attachment #2: backport-unstable-24459-to-xen-4.1-testing.patch --]
[-- Type: text/x-patch, Size: 1033 bytes --]

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>
Signed-off-by: Giam Teck Choon <giamteckchoon@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:34:28.000000000 +0800
@@ -1229,6 +1229,12 @@
     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],

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

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

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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],

Re: backport requests for 4.x-testing

[Ian Jackson]

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>

Re: backport requests for 4.x-testing

[Keir Fraser]

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

Re: backport requests for 4.x-testing

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

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


[-- Attachment #2: xen-unstable.hg-24870.9bf3ec036bef-ported.patch --]
[-- Type: text/x-patch, Size: 2550 bytes --]


# HG changeset patch
# User Andrew Cooper <andrew.cooper3@citrix.com>
# Date 1329991127 0
# Node ID 9bf3ec036bef2b67338bf5685423e26de69bd031
# Parent c0412e6399fdc5048b4eeefa6a45822890309c72
IO-APIC: Prevent using EOI broadcast suppression if user specified ioapic_ack=new on the command line.

Currently, if EOI broadcast suppression is advertised on the BSP
LAPIC, Xen will discard any user specified option regarding IO-APIC
ack mode.

This patch introduces a check which prevents EOI Broadcast suppression
from forcing the IO-APIC ack mode to old if the user has explicitly
asked for the new ack mode on the command line.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>

diff -r c0412e6399fd xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -437,9 +437,15 @@ int __init verify_local_APIC(void)
      */
     if ( reg0 & APIC_LVR_DIRECTED_EOI )
     {
-        ioapic_ack_new = 0;
-        directed_eoi_enabled = 1;
-        printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        if ( ioapic_ack_new == 1 && ioapic_ack_forced == 1 )
+            printk("Not enabling directed EOI because ioapic_ack_new has been "
+                   "forced on the command line\n");
+        else
+        {
+            ioapic_ack_new = 0;
+            directed_eoi_enabled = 1;
+            printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        }
     }
 
     /*
diff -r c0412e6399fd xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -44,6 +44,7 @@ static struct { int pin, apic; } ioapic_
 static DEFINE_SPINLOCK(ioapic_lock);
 
 bool_t __read_mostly skip_ioapic_setup;
+bool_t __read_mostly ioapic_ack_forced = 0;
 
 #ifndef sis_apic_bug
 /*
@@ -1664,9 +1665,15 @@ int __read_mostly ioapic_ack_new = 1;
 static void setup_ioapic_ack(char *s)
 {
     if ( !strcmp(s, "old") )
+    {
         ioapic_ack_new = 0;
+        ioapic_ack_forced = 1;
+    }
     else if ( !strcmp(s, "new") )
+    {
         ioapic_ack_new = 1;
+        ioapic_ack_forced = 1;
+    }
     else
         printk("Unknown ioapic_ack value specified: '%s'\n", s);
 }
diff -r c0412e6399fd xen/include/asm-x86/io_apic.h
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -179,6 +179,7 @@ static inline void io_apic_modify(unsign
 
 /* 1 if "noapic" boot option passed */
 extern bool_t skip_ioapic_setup;
+extern bool_t ioapic_ack_forced;
 
 #ifdef CONFIG_ACPI_BOOT
 extern int io_apic_get_unique_id (int ioapic, int apic_id);

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

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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
>> 
>> 

Re: backport requests for 4.x-testing

[Jan Beulich]

>>> 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

Re: backport requests for 4.x-testing

[Andrew Cooper]

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).
>
> Jan

Yes - 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

Re: backport requests for 4.x-testing

[Ian Campbell]

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.

Re: backport requests for 4.x-testing

[Andrew Cooper]

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Konrad Rzeszutek Wilk]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

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)


[-- Attachment #2: tools-two-new-calls.patch --]
[-- Type: text/plain, Size: 4583 bytes --]

# HG changeset patch
# Parent 476b0d68e7d5405babc1182da3b345b1e4cc1bca
libxc: xc_domain_set_memory_map, xc_get_machine_memory_map (x86, amd64 only)

The later retrieves the E820 as seen by the hypervisor (completely
unchanged) and the second call sets the E820 for the specified guest.

[backport of c/s 23412]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 476b0d68e7d5 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Sat Apr 30 09:48:16 2011 +0100
+++ b/tools/libxc/xc_domain.c	Wed May 04 08:57:40 2011 -0400
@@ -478,37 +478,64 @@ int xc_domain_pin_memory_cacheattr(xc_in
 }
 
 #if defined(__i386__) || defined(__x86_64__)
-#include "xc_e820.h"
+int xc_domain_set_memory_map(xc_interface *xch,
+                               uint32_t domid,
+                               struct e820entry entries[],
+                               uint32_t nr_entries)
+{
+    int rc;
+    struct xen_foreign_memory_map fmap = {
+        .domid = domid,
+        .map = { .nr_entries = nr_entries }
+    };
+    DECLARE_HYPERCALL_BOUNCE(entries, nr_entries * sizeof(struct e820entry),
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+    if ( !entries || xc_hypercall_bounce_pre(xch, entries) )
+        return -1;
+
+    set_xen_guest_handle(fmap.map.buffer, entries);
+
+    rc = do_memory_op(xch, XENMEM_set_memory_map, &fmap, sizeof(fmap));
+
+    xc_hypercall_bounce_post(xch, entries);
+
+    return rc;
+}
+int xc_get_machine_memory_map(xc_interface *xch,
+                              struct e820entry entries[],
+                              uint32_t max_entries)
+{
+    int rc;
+    struct xen_memory_map memmap = {
+        .nr_entries = max_entries
+    };
+    DECLARE_HYPERCALL_BOUNCE(entries, sizeof(struct e820entry) * max_entries,
+                             XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( !entries || xc_hypercall_bounce_pre(xch, entries) || max_entries <= 1)
+        return -1;
+
+
+    set_xen_guest_handle(memmap.buffer, entries);
+
+    rc = do_memory_op(xch, XENMEM_machine_memory_map, &memmap, sizeof(memmap));
+
+    xc_hypercall_bounce_post(xch, entries);
+
+    return rc ? rc : memmap.nr_entries;
+}
 int xc_domain_set_memmap_limit(xc_interface *xch,
                                uint32_t domid,
                                unsigned long map_limitkb)
 {
-    int rc;
-    struct xen_foreign_memory_map fmap = {
-        .domid = domid,
-        .map = { .nr_entries = 1 }
-    };
-    DECLARE_HYPERCALL_BUFFER(struct e820entry, e820);
+    struct e820entry e820;
 
-    e820 = xc_hypercall_buffer_alloc(xch, e820, sizeof(*e820));
+    e820.addr = 0;
+    e820.size = (uint64_t)map_limitkb << 10;
+    e820.type = E820_RAM;
 
-    if ( e820 == NULL )
-    {
-        PERROR("Could not allocate memory for xc_domain_set_memmap_limit hypercall");
-        return -1;
-    }
-
-    e820->addr = 0;
-    e820->size = (uint64_t)map_limitkb << 10;
-    e820->type = E820_RAM;
-
-    set_xen_guest_handle(fmap.map.buffer, e820);
-
-    rc = do_memory_op(xch, XENMEM_set_memory_map, &fmap, sizeof(fmap));
-
-    xc_hypercall_buffer_free(xch, e820);
-
-    return rc;
+    return xc_domain_set_memory_map(xch, domid, &e820, 1);
 }
 #else
 int xc_domain_set_memmap_limit(xc_interface *xch,
diff -r 476b0d68e7d5 tools/libxc/xc_e820.h
--- a/tools/libxc/xc_e820.h	Sat Apr 30 09:48:16 2011 +0100
+++ b/tools/libxc/xc_e820.h	Wed May 04 08:57:40 2011 -0400
@@ -26,6 +26,9 @@
 #define E820_RESERVED     2
 #define E820_ACPI         3
 #define E820_NVS          4
+#define E820_UNUSABLE     5
+
+#define E820MAX           (128)
 
 struct e820entry {
     uint64_t addr;
diff -r 476b0d68e7d5 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Sat Apr 30 09:48:16 2011 +0100
+++ b/tools/libxc/xenctrl.h	Wed May 04 08:57:40 2011 -0400
@@ -966,6 +966,17 @@ int xc_domain_set_memmap_limit(xc_interf
                                uint32_t domid,
                                unsigned long map_limitkb);
 
+#if defined(__i386__) || defined(__x86_64__)
+#include "xc_e820.h"
+int xc_domain_set_memory_map(xc_interface *xch,
+                               uint32_t domid,
+                               struct e820entry entries[],
+                               uint32_t nr_entries);
+
+int xc_get_machine_memory_map(xc_interface *xch,
+                              struct e820entry entries[],
+                              uint32_t max_entries);
+#endif
 int xc_domain_set_time_offset(xc_interface *xch,
                               uint32_t domid,
                               int32_t time_offset_seconds);

[-- Attachment #3: tools-fix-compile-error-out-of-tree.patch --]
[-- Type: text/plain, Size: 3500 bytes --]

# HG changeset patch
# Parent 5d31bd0eb8d040c0b44fe2a3b737fd752a607e74
libxc: Squash xc_e820.h (and delete) into xenctrl.h

.. as there is no need to keep that internal header file anymore.
We export two functions xc_domain_[set|get]_memory_map which
depend on the 'struct e820entry' defined in 'xc_e820.h'.

We move the contents of the 'xc_e820.h' to the 'xenctrl.h' fixing
compiler errors when applications outside the Xen tree are trying
to compile against the libraries.

[backport of c/s 23632]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 5d31bd0eb8d0 tools/libxc/xc_core_x86.c
--- a/tools/libxc/xc_core_x86.c	Wed Jun 01 16:10:50 2011 -0400
+++ b/tools/libxc/xc_core_x86.c	Mon Jun 13 13:41:31 2011 -0400
@@ -20,7 +20,7 @@
 
 #include "xg_private.h"
 #include "xc_core.h"
-#include "xc_e820.h"
+#include <xen/hvm/e820.h>
 
 #define GET_FIELD(_p, _f) ((dinfo->guest_width==8) ? ((_p)->x64._f) : ((_p)->x32._f))
 
diff -r 5d31bd0eb8d0 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Jun 01 16:10:50 2011 -0400
+++ b/tools/libxc/xc_domain_save.c	Mon Jun 13 13:41:31 2011 -0400
@@ -32,7 +32,6 @@
 #include "xg_save_restore.h"
 
 #include <xen/hvm/params.h>
-#include "xc_e820.h"
 
 /*
 ** Default values for important tuning parameters. Can override by passing
diff -r 5d31bd0eb8d0 tools/libxc/xc_e820.h
--- a/tools/libxc/xc_e820.h	Wed Jun 01 16:10:50 2011 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,39 +0,0 @@
-/*
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#ifndef __XC_E820_H__
-#define __XC_E820_H__
-
-#include <xen/hvm/e820.h>
-
-/*
- * PC BIOS standard E820 types and structure.
- */
-#define E820_RAM          1
-#define E820_RESERVED     2
-#define E820_ACPI         3
-#define E820_NVS          4
-#define E820_UNUSABLE     5
-
-#define E820MAX           (128)
-
-struct e820entry {
-    uint64_t addr;
-    uint64_t size;
-    uint32_t type;
-} __attribute__((packed));
-
-#endif /* __XC_E820_H__ */
diff -r 5d31bd0eb8d0 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Jun 01 16:10:50 2011 -0400
+++ b/tools/libxc/xenctrl.h	Mon Jun 13 13:41:31 2011 -0400
@@ -967,7 +967,22 @@ int xc_domain_set_memmap_limit(xc_interf
                                unsigned long map_limitkb);
 
 #if defined(__i386__) || defined(__x86_64__)
-#include "xc_e820.h"
+/*
+ * PC BIOS standard E820 types and structure.
+ */
+#define E820_RAM          1
+#define E820_RESERVED     2
+#define E820_ACPI         3
+#define E820_NVS          4
+#define E820_UNUSABLE     5
+
+#define E820MAX           (128)
+
+struct e820entry {
+    uint64_t addr;
+    uint64_t size;
+    uint32_t type;
+} __attribute__((packed));
 int xc_domain_set_memory_map(xc_interface *xch,
                                uint32_t domid,
                                struct e820entry entries[],

[-- Attachment #4: xen-e820-pv.patch --]
[-- Type: text/plain, Size: 4569 bytes --]

# HG changeset patch
# User Keir Fraser <keir@xen.org>
# Date 1302707426 -3600
# Node ID 3f00c5faa12aed4d0993391f71b7f12cf92f0208
# Parent eb3b40bf0ba21ca518fdc0b4f86cd49228bbb853
x86: make the pv-only e820 array be dynamic.

During creation of the PV domain we allocate the E820 structure to
have the amount of E820 entries on the machine, plus the number three.

This will allow the tool stack to fill the E820 with more than three
entries. Specifically the use cases is , where the toolstack retrieves
the E820, sanitizes it, and then sets it for the PV guest (for PCI
passthrough), this dynamic number of E820 is just right.

[backport of c/s 23225]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Keir Fraser <keir@xen.org>

diff -r eb3b40bf0ba2 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Tue Dec 13 14:12:56 2011 -0500
+++ b/xen/arch/x86/domain.c	Tue Dec 13 14:15:01 2011 -0500
@@ -557,6 +557,8 @@ int arch_domain_create(struct domain *d,
         /* 32-bit PV guest by default only if Xen is not 64-bit. */
         d->arch.is_32bit_pv = d->arch.has_32bit_shinfo =
             (CONFIG_PAGING_LEVELS != 4);
+
+        spin_lock_init(&d->arch.e820_lock);
     }
 
     memset(d->arch.cpuids, 0, sizeof(d->arch.cpuids));
@@ -603,6 +605,8 @@ void arch_domain_destroy(struct domain *
 
     if ( is_hvm_domain(d) )
         hvm_domain_destroy(d);
+    else
+        xfree(d->arch.e820);
 
     vmce_destroy_msr(d);
     pci_release_devices(d);
diff -r eb3b40bf0ba2 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Tue Dec 13 14:12:56 2011 -0500
+++ b/xen/arch/x86/mm.c	Tue Dec 13 14:15:01 2011 -0500
@@ -99,6 +99,7 @@
 #include <xen/event.h>
 #include <xen/iocap.h>
 #include <xen/guest_access.h>
+#include <xen/xmalloc.h>
 #include <asm/paging.h>
 #include <asm/shadow.h>
 #include <asm/page.h>
@@ -4667,11 +4668,12 @@ long arch_memory_op(int op, XEN_GUEST_HA
     {
         struct xen_foreign_memory_map fmap;
         struct domain *d;
+        struct e820entry *e820;
 
         if ( copy_from_guest(&fmap, arg, 1) )
             return -EFAULT;
 
-        if ( fmap.map.nr_entries > ARRAY_SIZE(d->arch.e820) )
+        if ( fmap.map.nr_entries > E820MAX )
             return -EINVAL;
 
         rc = rcu_lock_target_domain_by_id(fmap.domid, &d);
@@ -4685,9 +4687,25 @@ long arch_memory_op(int op, XEN_GUEST_HA
             return rc;
         }
 
-        rc = copy_from_guest(d->arch.e820, fmap.map.buffer,
-                             fmap.map.nr_entries) ? -EFAULT : 0;
+        e820 = xmalloc_array(e820entry_t, fmap.map.nr_entries);
+        if ( e820 == NULL )
+        {
+            rcu_unlock_domain(d);
+            return -ENOMEM;
+        }
+
+        if ( copy_from_guest(e820, fmap.map.buffer, fmap.map.nr_entries) )
+        {
+            xfree(e820);
+            rcu_unlock_domain(d);
+            return -EFAULT;
+        }
+
+        spin_lock(&d->arch.e820_lock);
+        xfree(d->arch.e820);
+        d->arch.e820 = e820;
         d->arch.nr_e820 = fmap.map.nr_entries;
+	spin_unlock(&d->arch.e820_lock);
 
         rcu_unlock_domain(d);
         return rc;
@@ -4698,18 +4716,28 @@ long arch_memory_op(int op, XEN_GUEST_HA
         struct xen_memory_map map;
         struct domain *d = current->domain;
 
-        /* Backwards compatibility. */
-        if ( d->arch.nr_e820 == 0 )
-            return -ENOSYS;
-
         if ( copy_from_guest(&map, arg, 1) )
             return -EFAULT;
 
+        spin_lock(&d->arch.e820_lock);
+
+        /* Backwards compatibility. */
+        if ( (d->arch.nr_e820 == 0) ||
+             (d->arch.e820 == NULL) )
+        {
+            spin_unlock(&d->arch.e820_lock);
+            return -ENOSYS;
+        }
+
         map.nr_entries = min(map.nr_entries, d->arch.nr_e820);
         if ( copy_to_guest(map.buffer, d->arch.e820, map.nr_entries) ||
              copy_to_guest(arg, &map, 1) )
+        {
+            spin_unlock(&d->arch.e820_lock);
             return -EFAULT;
-
+        }
+
+        spin_unlock(&d->arch.e820_lock);
         return 0;
     }
 
diff -r eb3b40bf0ba2 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Tue Dec 13 14:12:56 2011 -0500
+++ b/xen/include/asm-x86/domain.h	Tue Dec 13 14:15:01 2011 -0500
@@ -270,7 +270,8 @@ struct arch_domain
     unsigned long pirq_eoi_map_mfn;
 
     /* Pseudophysical e820 map (XENMEM_memory_map).  */
-    struct e820entry e820[3];
+    spinlock_t e820_lock;
+    struct e820entry *e820;
     unsigned int nr_e820;
 
     /* Maximum physical-address bitwidth supported by this guest. */

[-- Attachment #5: libxl-allocate-e820 --]
[-- Type: text/plain, Size: 10491 bytes --]

# HG changeset patch
# Parent 37cd883a764874bd5dfc8cfd6fbe82af1920a77e
libxl: Add support for passing in the host's E820 for PCI passthrough

The code that populates E820 is unconditionally triggered by the guest
configuration having "pci=['<BDF>,..']", being a PV guest, and if
b_info->u.pv.e820_host is set.

The code do_domain_create calls the libxl__e820_alloc when
it notices that the guest is PV, has at least one PCI devices, and has
the e820_host flag set.

libxl__e820_alloc calls the xc_get_machine_memory_map to retrieve the systems
E820. Then the E820 is sanitized to weed out E820 entries below 16MB, and as
well remove any E820_RAM or E820_UNUSED regions as the guest does not need to
know about them. The guest only needs the E820_ACPI, E820_NVS, E820_RESERVED to
get an idea of where the PCI I/O space is. Mostly.. The Linux kernel assumes that any
gap in the E820 is considered PCI I/O space which means that if we pass
in the guest 2GB, and the E820_ACPI, and its friend start at 3GB, the
gap between 2GB and 3GB will be considered as PCI I/O space. To guard against
that we also create an E820_UNUSABLE between the region of 'target_kb'
(called ram_end in the code) up to the first E820_[ACPI,NVS,RESERVED] region.
Lastly, the xc_domain_set_memory_map is called to install the new E820.

When tested with another PV guest (NetBSD 5.1) the modified E820 gave
it no trouble. The code has also been tested with older "classic" Xen Linux
and with the newer "pvops" with success (SLES11, RHEL5, Ubuntu Lucid,
Debian Squeeze, 2.6.37, 2.6.38, 2.6.39).

Memory that is slack or for balloon (so 'maxmem' in guest configuration)
is put behind the machine E820. Which in most cases is after the 4GB.

The reason for doing the fetching of the E820 using the hypercall in
the toolstack (instead of the guest doing it) is that when a guest
would do a hypercall to 'XENMEM_machine_memory_map' it would
retrieve an E820 with I/O range caps added in. Meaning that the
region after 4GB up to end of possible memory would be marked as unusable
and the kernel would not have any space to allocate a balloon
region.

[backport of c/s 23426]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 37cd883a7648 tools/libxl/libxl.idl
--- a/tools/libxl/libxl.idl	Wed Apr 13 16:10:26 2011 +0100
+++ b/tools/libxl/libxl.idl	Wed Nov 16 16:06:34 2011 -0500
@@ -117,6 +117,7 @@ libxl_domain_build_info = Struct("domain
                                         ("cmdline", string),
                                         ("ramdisk", libxl_file_reference),
                                         ("features", string, True),
+                                        ("e820_host", bool, False, "Use host's E820 for PCI passthrough."),
                                         ])),
                  ])),
     ],
diff -r 37cd883a7648 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Apr 13 16:10:26 2011 +0100
+++ b/tools/libxl/libxl_create.c	Wed Nov 16 16:06:34 2011 -0500
@@ -540,6 +540,14 @@ static int do_domain_create(libxl_ctx *c
     for (i = 0; i < d_config->num_pcidevs; i++)
         libxl__device_pci_add(ctx, domid, &d_config->pcidevs[i], 1);
 
+    if (!d_config->c_info.hvm && d_config->b_info.u.pv.e820_host) {
+        int rc;
+        rc = libxl__e820_alloc(ctx, domid, d_config);
+        if (rc)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                      "Failed while collecting E820 with: %d (errno:%d)\n",
+                      rc, errno);
+    }
     if ( cb && (d_config->c_info.hvm || d_config->b_info.u.pv.bootloader )) {
         if ( (*cb)(ctx, domid, priv) )
             goto error_out;
diff -r 37cd883a7648 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Apr 13 16:10:26 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Nov 16 16:06:34 2011 -0500
@@ -330,4 +330,5 @@ _hidden int libxl__error_set(libxl_ctx *
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
 
+_hidden int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_config *d_config);
 #endif
diff -r 37cd883a7648 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Apr 13 16:10:26 2011 +0100
+++ b/tools/libxl/libxl_pci.c	Wed Nov 16 16:06:34 2011 -0500
@@ -1079,3 +1079,167 @@ int libxl_device_pci_shutdown(libxl_ctx 
     free(pcidevs);
     return 0;
 }
+
+static const char *e820_names(int type)
+{
+    switch (type) {
+        case E820_RAM: return "RAM";
+        case E820_RESERVED: return "Reserved";
+        case E820_ACPI: return "ACPI";
+        case E820_NVS: return "ACPI NVS";
+        case E820_UNUSABLE: return "Unusable";
+        default: break;
+    }
+    return "Unknown";
+}
+
+static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
+                         uint32_t *nr_entries,
+                         unsigned long map_limitkb,
+                         unsigned long balloon_kb)
+{
+    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
+    uint32_t i, idx = 0, nr;
+    struct e820entry e820[E820MAX];
+
+    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
+        return ERROR_INVAL;
+
+    nr = *nr_entries;
+    if (!nr)
+        return ERROR_INVAL;
+
+    if (nr > E820MAX)
+        return ERROR_NOMEM;
+
+    /* Weed out anything under 1MB */
+    for (i = 0; i < nr; i++) {
+        if (src[i].addr > 0x100000)
+            continue;
+
+        src[i].type = 0;
+        src[i].size = 0;
+        src[i].addr = -1ULL;
+    }
+
+    /* Find the lowest and highest entry in E820, skipping over
+     * undesired entries. */
+    start = -1ULL;
+    last = 0;
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == E820_UNUSABLE) ||
+            (src[i].type == 0))
+		continue;
+
+        start = src[i].addr < start ? src[i].addr : start;
+        last = src[i].addr + src[i].size > last ?
+               src[i].addr + src[i].size > last : last;
+    }
+    if (start > 1024)
+        start_kb = start >> 10;
+
+    /* Add the memory RAM region for the guest */
+    e820[idx].addr = 0;
+    e820[idx].size = (uint64_t)map_limitkb << 10;
+    e820[idx].type = E820_RAM;
+
+    /* .. and trim if neccessary */
+    if (start_kb && map_limitkb > start_kb) {
+        delta_kb = map_limitkb - start_kb;
+        if (delta_kb)
+            e820[idx].size -= (uint64_t)(delta_kb << 10);
+    }
+    /* Note: We don't touch balloon_kb here. Will add it at the end. */
+    ram_end = e820[idx].addr + e820[idx].size;
+    idx ++;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
+               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
+               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
+               ram_end >> 12, delta_kb, start_kb ,start >> 12,
+               (uint64_t)balloon_kb);
+
+    /* Check if there is a region between ram_end and start. */
+    if (start > ram_end) {
+        /* .. and if not present, add it in. This is to guard against
+          the Linux guest assuming that the gap between the end of
+          RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+          is PCI I/O space. Which it certainly is _not_. */
+        e820[idx].type = E820_UNUSABLE;
+        e820[idx].addr = ram_end;
+        e820[idx].size = start - ram_end;
+        idx++;
+    }
+    /* Almost done: copy them over, ignoring the undesireable ones */
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+	    (src[i].type == E820_UNUSABLE) ||
+	    (src[i].type == 0))
+	    continue;
+
+        e820[idx].type = src[i].type;
+        e820[idx].addr = src[i].addr;
+        e820[idx].size = src[i].size;
+        idx++;
+    }
+    /* At this point we have the mapped RAM + E820 entries from src. */
+    if (balloon_kb) {
+        /* and if we truncated the RAM region, then add it to the end. */
+        e820[idx].type = E820_RAM;
+        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
+                         (uint64_t)(1ULL << 32) : last;
+        /* also add the balloon memory to the end. */
+        e820[idx].size = (uint64_t)(delta_kb << 10) +
+                         (uint64_t)(balloon_kb << 10);
+        idx++;
+
+    }
+    nr = idx;
+
+    for (i = 0; i < nr; i++) {
+      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
+                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
+                 e820_names(e820[i].type));
+    }
+
+    /* Done: copy the sanitized version. */
+    *nr_entries = nr;
+    memcpy(src, e820, nr * sizeof(struct e820entry));
+    return 0;
+}
+
+int libxl__e820_alloc(libxl_ctx *ctx, uint32_t domid, libxl_domain_config *d_config)
+{
+    int rc;
+    uint32_t nr;
+    struct e820entry map[E820MAX];
+    libxl_domain_build_info *b_info;
+
+    if (d_config == NULL || d_config->c_info.hvm)
+        return ERROR_INVAL;
+
+    b_info = &d_config->b_info;
+    if (!b_info->u.pv.e820_host)
+        return ERROR_INVAL;
+
+    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
+    if (rc < 0) {
+        errno = rc;
+        return ERROR_FAIL;
+    }
+    nr = rc;
+    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
+                       (b_info->max_memkb - b_info->target_memkb) +
+                       b_info->u.pv.slack_memkb);
+    if (rc)
+        return ERROR_FAIL;
+
+    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
+
+    if (rc < 0) {
+        errno  = rc;
+        return ERROR_FAIL;
+    }
+    return 0;
+}
diff -r 37cd883a7648 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Apr 13 16:10:26 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Nov 16 16:06:34 2011 -0500
@@ -371,6 +371,7 @@ static void printf_info(int domid,
         printf("\t\t\t(kernel %s)\n", b_info->kernel.path);
         printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
         printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
+        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
         printf("\t\t)\n");
     }
     printf("\t)\n");
@@ -1025,6 +1026,8 @@ skip_vfb:
             if (!libxl_device_pci_parse_bdf(&ctx, pcidev, buf))
                 d_config->num_pcidevs++;
         }
+        if (d_config->num_pcidevs && !c_info->hvm)
+            b_info->u.pv.e820_host = true;
     }
 
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {

[-- Attachment #6: libxl_e820_override --]
[-- Type: text/plain, Size: 2182 bytes --]

# HG changeset patch
# Parent 615d58973988e505c4cff62a338225152ceaa052
libxl: Add 'e820_host' option to config file.

.. which will be removed once the auto-ballooning of guests
with PCI devices works. During testing of the patches which provide
a host E820 in a PV guest, certain inconsistencies were found with
guests. When launching a RHEL5 or SLES11 PV guest with 4GB and a PCI device,
the kernel would report 4GB, but have 1.5G "used". What happend was that
the P2M that fall within the E820 I/O holes would never be used and was just
wasted. The mechanism to go around this is to shrink the size of the guest
before launch (say memory=2048, maxmem=4096) and then balloon back to 4096M
after start. For PVOPS type kernels it would detect the E820 I/O holes and
deflate by the correct amount but would not inflate back to 4GB.
Manually inflating makes it work.

The fix in the future for guests where the memory amount flows over the
PCI hole, is to launch the guest with decreased amount right up to the cusp
of where the E820 PCI hole starts. Also increase the 'maxmem' by the delta
and then when the guest has launched, balloon up to the delta number.

This will require some careful surgery so for right now this parameter
will guard against unsuspecting users seeing their PV guests memory "vanish."

[backport of c/s 23428]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 615d58973988 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Nov 16 16:06:34 2011 -0500
+++ b/tools/libxl/xl_cmdimpl.c	Wed Nov 16 16:06:44 2011 -0500
@@ -1010,6 +1010,16 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
         pci_power_mgmt = l;
 
+    /* To be reworked (automatically enabled) once the auto ballooning
+     * after guest starts is done (with PCI devices passed in). */
+    if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+        if (c_info->hvm)
+          fprintf(stderr, "Can't do e820_host in HVM mode!");
+        else {
+          if (l)
+            b_info->u.pv.e820_host = true;
+        }
+    }
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;

[-- Attachment #7: libxl-fix-unused-ram-e820 --]
[-- Type: text/plain, Size: 9058 bytes --]

# HG changeset patch
# Parent d825fb0ba571f9f15c7fe1bb19c85c3568c0bb6f
libxl: Convert E820_UNUSABLE and E820_RAM to E820_UNUSABLE as appropriate.

Most machines after the RAM regions in the e802 have a couple of
E820_RESERVED, with E820_ACPI and E820_NVS. On some Intel machines, the
E820 looks like swiss cheese:

(XEN) Initial Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d000 (usable)
(XEN)  000000000009d000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000009cf66000 (usable)
(XEN)  000000009cf66000 - 000000009d102000 (ACPI NVS)
(XEN)  000000009d102000 - 000000009f6bd000 (usable)  <--
(XEN)  000000009f6bd000 - 000000009f6bf000 (reserved)
(XEN)  000000009f6bf000 - 000000009f714000 (usable)  <--
(XEN)  000000009f714000 - 000000009f7bf000 (ACPI NVS)
(XEN)  000000009f7bf000 - 000000009f7e0000 (usable)  <--
(XEN)  000000009f7e0000 - 000000009f7ff000 (ACPI data)
(XEN)  000000009f7ff000 - 000000009f800000 (usable)  <--
(XEN)  000000009f800000 - 00000000a0000000 (reserved)
(XEN)  00000000a0000000 - 00000000b0000000 (reserved)
(XEN)  00000000fc000000 - 00000000fd000000 (reserved)
(XEN)  00000000ffe00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000160000000 (usable)

Which means we have to pay attention to the E820_RAM that are
between the E820_[ACPI,NVS,RESERVED]. If we remove those
E820_RAM (b/c the amount of memory passed to the guest
is less that where those E820 regions reside) from the E820, the
Linux kernel interprets those "gaps" as PCI I/O space.
This is what we are currently doing.

This can be disastrous if we pass in an Intel IGD card which tries
to use the first available PCI I/O space - and ends up
using the MFNs which are actually RAM instead of being the
PCI I/O space.

To make this work, we convert all E820_RAM that are above
the 'target_kb' (those that overlap the 'target_kb'
are truncated appropriately) to be E820_UNUSABLE. We also limit this
alternation up to 4GB. This means that an E820 for a guest
from this (target_kb=1024, maxmem=2048):

[    0.000000] Set 405658 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 000000009cf66000 (unusable)
[    0.000000]  Xen: 000000009cf66000 - 000000009d102000 (ACPI NVS)
[    0.000000]  Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
[    0.000000]  Xen: 000000009f714000 - 000000009f7bf000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7e0000 - 000000009f7ff000 (ACPI data)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fc000000 - 00000000fd000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000140800000 (usable)


Will look as so:

[    0.000000] Set 395880 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 000000009cf66000 (unusable)
[    0.000000]  Xen: 000000009cf66000 - 000000009d102000 (ACPI NVS)
[    0.000000]  Xen: 000000009d102000 - 000000009f6bd000 (unusable)
[    0.000000]  Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
[    0.000000]  Xen: 000000009f6bf000 - 000000009f714000 (unusable)
[    0.000000]  Xen: 000000009f714000 - 000000009f7bf000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7bf000 - 000000009f7e0000 (unusable)
[    0.000000]  Xen: 000000009f7e0000 - 000000009f7ff000 (ACPI data)
[    0.000000]  Xen: 000000009f7ff000 - 000000009f800000 (unusable)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fc000000 - 00000000fd000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000140800000 (usable)

[backport of c/s 23427]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r d825fb0ba571 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Nov 16 16:06:44 2011 -0500
+++ b/tools/libxl/libxl_pci.c	Wed Nov 16 16:06:50 2011 -0500
@@ -1160,21 +1160,98 @@ static int e820_sanitize(libxl_ctx *ctx,
                ram_end >> 12, delta_kb, start_kb ,start >> 12,
                (uint64_t)balloon_kb);
 
+
+    /* This whole code below is to guard against if the Intel IGD is passed into
+     * the guest. If we don't pass in IGD, this whole code can be ignored.
+     *
+     * The reason for this code is that Intel boxes fill their E820 with
+     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
+     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
+     * Linux and it would be utilized by the Intel IGD as I/O space while
+     * in reality it was an RAM region.
+     *
+     * What this means is that we have to walk the E820 and for any region
+     * that is RAM and below 4GB and above ram_end, needs to change its type
+     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
+     * the overlap with ram_end. */
+    for (i = 0; i < nr; i++) {
+	uint64_t end = src[i].addr + src[i].size;
+
+	/* We don't care about E820_UNUSABLE, but we need to
+         * change the type to zero b/c the loop after this
+         * sticks E820_UNUSABLE on the guest's E820 but ignores
+         * the ones with type zero. */
+        if ((src[i].type == E820_UNUSABLE) ||
+	    /* Any region that is within the "RAM region" can
+             * be safely ditched. */
+            (end < ram_end)) {
+                src[i].type = 0;
+                continue;
+        }
+
+        /* Look only at RAM regions. */
+	if (src[i].type != E820_RAM)
+            continue;
+
+        /* We only care about RAM regions below 4GB. */
+        if (src[i].addr >= (1ULL<<32))
+            continue;
+
+	/* E820_RAM overlaps with our RAM region. Move it */
+	if (src[i].addr < ram_end) {
+            uint64_t delta;
+
+            src[i].type = E820_UNUSABLE;
+            delta = ram_end - src[i].addr;
+            /* The end < ram_end should weed this out */
+            if (src[i].size - delta < 0)
+                src[i].type = 0;
+            else {
+                src[i].size -= delta;
+                src[i].addr = ram_end;
+            }
+            if (src[i].addr + src[i].size != end) {
+                /* We messed up somewhere */
+                src[i].type = 0;
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
+            }
+        }
+        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
+           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
+            "xen/setup: Inhibit resource API from using System RAM E820
+           gaps as PCI mem gaps" for full explanation. */
+        if (end > ram_end)
+            src[i].type = E820_UNUSABLE;
+    }
+
     /* Check if there is a region between ram_end and start. */
     if (start > ram_end) {
+        int add_unusable = 1;
+        for (i = 0; i < nr && add_unusable; i++) {
+            if (src[i].type != E820_UNUSABLE)
+                continue;
+            if (ram_end != src[i].addr)
+                continue;
+            if (start != src[i].addr + src[i].size) {
+                /* there is one, adjust it */
+                src[i].size = start - src[i].addr;
+            }
+            add_unusable = 0;
+        }
         /* .. and if not present, add it in. This is to guard against
-          the Linux guest assuming that the gap between the end of
-          RAM region and the start of the E820_[ACPI,NVS,RESERVED]
-          is PCI I/O space. Which it certainly is _not_. */
-        e820[idx].type = E820_UNUSABLE;
-        e820[idx].addr = ram_end;
-        e820[idx].size = start - ram_end;
-        idx++;
+           the Linux guest assuming that the gap between the end of
+           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+           is PCI I/O space. Which it certainly is _not_. */
+        if (add_unusable) {
+            e820[idx].type = E820_UNUSABLE;
+            e820[idx].addr = ram_end;
+            e820[idx].size = start - ram_end;
+            idx++;
+        }
     }
     /* Almost done: copy them over, ignoring the undesireable ones */
     for (i = 0; i < nr; i++) {
         if ((src[i].type == E820_RAM) ||
-	    (src[i].type == E820_UNUSABLE) ||
 	    (src[i].type == 0))
 	    continue;
 

[-- Attachment #8: 24013-allows-vcpu_register_for_hvm_domains.patch --]
[-- Type: text/plain, Size: 1311 bytes --]

# HG changeset patch
# User Zhenzhong Duan <zhenzhong.duan@oracle.com>
# Date 1319818821 -3600
# Node ID c4ed56a102dc3a66dc4dda6ed1584cb6531074a2
# Parent  2e16d8e6a965be8f62c99c6e456988cfa72b7e1d
x86,hvm: enable VCPUOP_register_vcpu_info op in hvm hypercall

pvhvm running with more than 32 vcpus and pv_irq/pv_time enabled
need vcpu placement to work, or else it will softlockup.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Committed-by: Keir Fraser <keir@xen.org>
[backport of c/s 24013]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
diff -r 2e16d8e6a965 -r c4ed56a102dc xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Oct 28 17:17:47 2011 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Fri Oct 28 17:20:21 2011 +0100
@@ -2794,6 +2794,7 @@ static long hvm_vcpu_op(
     case VCPUOP_stop_periodic_timer:
     case VCPUOP_set_singleshot_timer:
     case VCPUOP_stop_singleshot_timer:
+    case VCPUOP_register_vcpu_info:
         rc = do_vcpu_op(cmd, vcpuid, arg);
         break;
     default:
@@ -2869,6 +2870,7 @@ static long hvm_vcpu_op_compat32(
     case VCPUOP_stop_periodic_timer:
     case VCPUOP_set_singleshot_timer:
     case VCPUOP_stop_singleshot_timer:
+    case VCPUOP_register_vcpu_info:
         rc = compat_vcpu_op(cmd, vcpuid, arg);
         break;
     default:

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

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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.

 -- Keir

> which I've back-ported to 4.1 (please see attachments)
> 

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Konrad Rzeszutek Wilk]

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?
> 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

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Konrad Rzeszutek Wilk]

> >> > 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.

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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.

Re: backport requests for 4.x-testing

[Konrad Rzeszutek Wilk]

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.

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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!

Re: backport requests for 4.x-testing

[Stefano Stabellini]

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 hypercall
 
What 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

Re: backport requests for 4.x-testing

[Jan Beulich]

>>> 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.

Jan

Re: backport requests for 4.x-testing

[Stefano Stabellini]

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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. */

Re: backport requests for 4.x-testing

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 7407 bytes --]

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

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

From 783c980463c6b70725796f4706385fdf332fc4f8 Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 29 Mar 2012 11:37:04 +0000
Subject: [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


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

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

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Teck Choon Giam]

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

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Teck Choon Giam]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

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

[-- Attachment #2: backport-unstable-25131-to-xen-4.1-testing.patch --]
[-- Type: application/octet-stream, Size: 2397 bytes --]

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 |   14 ++++++++++++++
 3 files changed, 19 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..6bace41 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -737,6 +737,20 @@ 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;
 

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

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

Re: backport requests for 4.x-testing

[Ian Jackson]

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.

Re: backport requests for 4.x-testing

[Keir Fraser]

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

Re: backport requests for 4.x-testing

[Jan Beulich]

>>> 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

Re: backport requests for 4.x-testing

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

>>> 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


[-- Attachment #2: 24527-AMD-Vi-fault-softirq.patch --]
[-- Type: text/plain, Size: 4459 bytes --]

# HG changeset patch
# User Dario Faggioli <dario.faggioli@citrix.com>
# Date 1327054832 0
# Node ID 028230eb2359f33da48b3b7f85173a1b49b9c7d6
# Parent  d600a3d7faeeee3cf947bf1658b873e966fc0f16
iommu: Move IOMMU faults handling into softirq for AMD-Vi.

Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a
softirq-tasklet, raised by the actual IRQ handler. To avoid more
interrupts being generated (because of further faults), they must be
masked in the IOMMU within the low level IRQ handler and enabled back
in the tasklet body. Notice that this may cause the log to overflow,
but none of the existing entry will be overwritten.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -33,6 +33,8 @@ static int nr_amd_iommus;
 static long amd_iommu_cmd_buffer_entries = IOMMU_CMD_BUFFER_DEFAULT_ENTRIES;
 static long amd_iommu_event_log_entries = IOMMU_EVENT_LOG_DEFAULT_ENTRIES;
 
+static struct tasklet amd_iommu_irq_tasklet;
+
 unsigned short ivrs_bdf_entries;
 struct ivrs_mappings *ivrs_mappings;
 struct list_head amd_iommu_head;
@@ -517,34 +519,70 @@ static void parse_event_log_entry(u32 en
     }
 }
 
+static void do_amd_iommu_irq(unsigned long data)
+{
+    struct amd_iommu *iommu;
+
+    if ( !iommu_found() )
+    {
+        AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n");
+        return;
+   }
+
+    /*
+     * No matter from where the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMUs).
+     */
+    for_each_amd_iommu ( iommu )
+    {
+        u32 entry;
+        unsigned long flags;
+        int of;
+
+        spin_lock_irqsave(&iommu->lock, flags);
+        amd_iommu_read_event_log(iommu);
+
+        /* check event overflow */
+        entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+        of = get_field_from_reg_u32(entry,
+                                   IOMMU_STATUS_EVENT_OVERFLOW_MASK,
+                                   IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
+
+        /* reset event log if event overflow */
+        if ( of )
+            amd_iommu_reset_event_log(iommu);
+
+        /* reset interrupt status bit */
+        entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+        set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                             IOMMU_STATUS_EVENT_LOG_INT_MASK,
+                             IOMMU_STATUS_EVENT_LOG_INT_SHIFT, &entry);
+        writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+        spin_unlock_irqrestore(&iommu->lock, flags);
+    }
+}
+
 static void amd_iommu_page_fault(int irq, void *dev_id,
                              struct cpu_user_regs *regs)
 {
     u32 entry;
     unsigned long flags;
-    int of;
     struct amd_iommu *iommu = dev_id;
 
     spin_lock_irqsave(&iommu->lock, flags);
-    amd_iommu_read_event_log(iommu);
 
-    /*check event overflow */
+    /* Silence interrupts from both event logging */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-    of = get_field_from_reg_u32(entry,
-                               IOMMU_STATUS_EVENT_OVERFLOW_MASK,
-                               IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
-
-    /* reset event log if event overflow */
-    if ( of )
-        amd_iommu_reset_event_log(iommu);
-
-    /* reset interrupt status bit */
-    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+    set_field_in_reg_u32(IOMMU_CONTROL_DISABLED, entry,
                          IOMMU_STATUS_EVENT_LOG_INT_MASK,
                          IOMMU_STATUS_EVENT_LOG_INT_SHIFT, &entry);
     writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+
     spin_unlock_irqrestore(&iommu->lock, flags);
+
+    /* It is the tasklet that will clear the logs and re-enable interrupts */
+    tasklet_schedule(&amd_iommu_irq_tasklet);
 }
 
 static int set_iommu_interrupt_handler(struct amd_iommu *iommu)
@@ -689,6 +727,8 @@ static int __init amd_iommu_init_one(str
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
 
+    softirq_tasklet_init(&amd_iommu_irq_tasklet, do_amd_iommu_irq, 0);
+
     return 0;
 
 error_out:

[-- Attachment #3: 23900-xzalloc.patch --]
[-- Type: text/plain, Size: 2834 bytes --]

# HG changeset patch
# User Jan Beulich <jbeulich@suse.com>
# Date 1317730526 -7200
# Node ID e09ebf7a31f55bb26c3cce7695a435ed20adf05b
# Parent  a99d75671a911f9c0d5d11e0fe88a0a65863cb44
introduce xzalloc() & Co

Rather than having to match a call to one of the xmalloc() flavors with
a subsequent memset(), introduce a zeroing variant of each of those
flavors.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>

--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -585,6 +585,13 @@ void *_xmalloc(unsigned long size, unsig
     return p;
 }
 
+void *_xzalloc(unsigned long size, unsigned long align)
+{
+    void *p = _xmalloc(size, align);
+
+    return p ? memset(p, 0, size) : p;
+}
+
 void xfree(void *p)
 {
     struct bhdr *b;
--- a/xen/include/acpi/platform/aclinux.h
+++ b/xen/include/acpi/platform/aclinux.h
@@ -77,10 +77,7 @@
 #define acpi_thread_id struct vcpu *
 
 #define ACPI_ALLOCATE(a)	xmalloc_bytes(a)
-#define ACPI_ALLOCATE_ZEROED(a)	({              \
-    void *p = xmalloc_bytes(a);                 \
-    if ( p ) memset(p, 0, a);                   \
-    p; })
+#define ACPI_ALLOCATE_ZEROED(a)	xzalloc_bytes(a)
 #define ACPI_FREE(a)		xfree(a)
 
 #endif				/* __ACLINUX_H__ */
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -8,19 +8,25 @@
 
 /* Allocate space for typed object. */
 #define xmalloc(_type) ((_type *)_xmalloc(sizeof(_type), __alignof__(_type)))
+#define xzalloc(_type) ((_type *)_xzalloc(sizeof(_type), __alignof__(_type)))
 
 /* Allocate space for array of typed objects. */
 #define xmalloc_array(_type, _num) \
     ((_type *)_xmalloc_array(sizeof(_type), __alignof__(_type), _num))
+#define xzalloc_array(_type, _num) \
+    ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num))
 
 /* Allocate untyped storage. */
-#define xmalloc_bytes(_bytes) (_xmalloc(_bytes, SMP_CACHE_BYTES))
+#define xmalloc_bytes(_bytes) _xmalloc(_bytes, SMP_CACHE_BYTES)
+#define xzalloc_bytes(_bytes) _xzalloc(_bytes, SMP_CACHE_BYTES)
 
 /* Free any of the above. */
 extern void xfree(void *);
 
 /* Underlying functions */
 extern void *_xmalloc(unsigned long size, unsigned long align);
+extern void *_xzalloc(unsigned long size, unsigned long align);
+
 static inline void *_xmalloc_array(
     unsigned long size, unsigned long align, unsigned long num)
 {
@@ -30,6 +36,15 @@ static inline void *_xmalloc_array(
  	return _xmalloc(size * num, align);
 }
 
+static inline void *_xzalloc_array(
+    unsigned long size, unsigned long align, unsigned long num)
+{
+    /* Check for overflow. */
+    if (size && num > UINT_MAX / size)
+        return NULL;
+    return _xzalloc(size * num, align);
+}
+
 /*
  * Pooled allocator interface.
  */

[-- Attachment #4: 24156-x86-ioapic-shared-vectors.patch --]
[-- Type: text/plain, Size: 5123 bytes --]

# HG changeset patch
# User Jan Beulich <jbeulich@suse.com>
# Date 1321604484 -3600
# Node ID f29b5bd6e25fd78409baa5461914c67065f7579f
# Parent  0d50e704834fb53c6c86b8b0badd19d88e73c4ed
x86/IRQ: prevent vector sharing within IO-APICs

Following the prevention of vector sharing for MSIs, this change
enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
as their identifying device under the AMD IOMMU (and just like for
MSIs, only the identifying device is used to remap interrupts here,
with no regard to an interrupt's destination).

Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
use only the vector for identifying which interrupts to end. While this
generally causes no significant problem (at worst an interrupt would be
re-raised without a new interrupt event actually having occurred), it
still seems better to avoid the situation.

For this second aspect, a distinction is being made between the
traditional and the directed-EOI cases: In the former, vectors should
not be shared throughout all IO-APICs in the system, while in the
latter case only individual IO-APICs need to be contrained (or, if the
firmware indicates so, sub- groups of them having the same GSI appear
at multiple pins).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -70,6 +70,34 @@ int __read_mostly nr_ioapics;
 
 #define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20)
 
+static int apic_pin_2_gsi_irq(int apic, int pin);
+
+static vmask_t *__read_mostly vector_map[MAX_IO_APICS];
+
+static void share_vector_maps(unsigned int src, unsigned int dst)
+{
+    unsigned int pin;
+
+    if (vector_map[src] == vector_map[dst])
+        return;
+
+    bitmap_or(vector_map[src]->_bits, vector_map[src]->_bits,
+              vector_map[dst]->_bits, NR_VECTORS);
+
+    for (pin = 0; pin < nr_ioapic_registers[dst]; ++pin) {
+        int irq = apic_pin_2_gsi_irq(dst, pin);
+        struct irq_cfg *cfg;
+
+        if (irq < 0)
+            continue;
+        cfg = irq_cfg(irq);
+        if (cfg->used_vectors == vector_map[dst])
+            cfg->used_vectors = vector_map[src];
+    }
+
+    vector_map[dst] = vector_map[src];
+}
+
 /*
  * This is performance-critical, we want to do it O(1)
  *
@@ -110,6 +138,7 @@ static void add_pin_to_irq(unsigned int 
     }
     entry->apic = apic;
     entry->pin = pin;
+    share_vector_maps(irq_2_pin[irq].apic, apic);
 }
 
 /*
@@ -125,6 +154,7 @@ static void __init replace_pin_at_irq(un
         if (entry->apic == oldapic && entry->pin == oldpin) {
             entry->apic = newapic;
             entry->pin = newpin;
+            share_vector_maps(oldapic, newapic);
         }
         if (!entry->next)
             break;
@@ -132,6 +162,16 @@ static void __init replace_pin_at_irq(un
     }
 }
 
+vmask_t *io_apic_get_used_vector_map(unsigned int irq)
+{
+    struct irq_pin_list *entry = irq_2_pin + irq;
+
+    if (entry->pin == -1)
+        return NULL;
+
+    return vector_map[entry->apic];
+}
+
 struct IO_APIC_route_entry **alloc_ioapic_entries(void)
 {
     int apic;
@@ -1294,6 +1334,18 @@ static void __init enable_IO_APIC(void)
     for (i = irq_2_pin_free_entry = nr_irqs_gsi; i < PIN_MAP_SIZE; i++)
         irq_2_pin[i].next = i + 1;
 
+    if (directed_eoi_enabled) {
+        for (apic = 0; apic < nr_ioapics; apic++) {
+            vector_map[apic] = xzalloc(vmask_t);
+            BUG_ON(!vector_map[apic]);
+        }
+    } else {
+        vector_map[0] = xzalloc(vmask_t);
+        BUG_ON(!vector_map[0]);
+        for (apic = 1; apic < nr_ioapics; apic++)
+            vector_map[apic] = vector_map[0];
+    }
+
     for(apic = 0; apic < nr_ioapics; apic++) {
         int pin;
         /* See if any of the pins is in ExtINT mode */
@@ -2465,13 +2517,12 @@ int ioapic_guest_write(unsigned long phy
     }
 
     if ( cfg->vector <= 0 || cfg->vector > LAST_DYNAMIC_VECTOR ) {
+        add_pin_to_irq(irq, apic, pin);
         vector = assign_irq_vector(irq);
         if ( vector < 0 )
             return vector;
 
         printk(XENLOG_INFO "allocated vector %02x for irq %d\n", vector, irq);
-
-        add_pin_to_irq(irq, apic, pin);
     }
     spin_lock(&pcidevs_lock);
     spin_lock(&dom0->event_lock);
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -403,6 +403,11 @@ static vmask_t *irq_get_used_vector_mask
             }
         }
     }
+    else if ( IO_APIC_IRQ(irq) &&
+              opt_irq_vector_map != OPT_IRQ_VECTOR_MAP_NONE )
+    {
+        ret = io_apic_get_used_vector_map(irq);
+    }
 
     return ret;
 }
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -113,6 +113,7 @@ void setup_IO_APIC(void);
 void disable_IO_APIC(void);
 void print_IO_APIC(void);
 void setup_ioapic_dest(void);
+vmask_t *io_apic_get_used_vector_map(unsigned int irq);
 
 extern unsigned long io_apic_irqs;
 

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

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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
> 

Re: backport requests for 4.x-testing

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

>>> 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


[-- Attachment #2: 24535-x86-vMSI-misc.patch --]
[-- Type: text/plain, Size: 6034 bytes --]

# HG changeset patch
# User Jan Beulich <jbeulich@suse.com>
# Date 1327311317 0
# Node ID fb81b807c1540eb5797b3daa4bddff99363b20ef
# Parent  eca719b621a1201528bfec25fb1786ec21c0c9d3
x86/vMSI: miscellaneous fixes

This addresses a number of problems in msixtbl_{read,write}():
- address alignment was not checked, allowing for memory corruption in
  the hypervisor (write case) or returning of hypervisor private data
  to the guest (read case)
- the interrupt mask bit was permitted to be written by the guest
  (while Xen's interrupt flow control routines need to control it)
- MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
  numbers (making it unobvious why they have these values, and making
  the latter non-portable)
- MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
  non-zero table offset); this was also affecting host MSI-X code
- struct msixtbl_entry's table_flags[] was one element larger than
  necessary due to improper open-coding of BITS_TO_LONGS()
- msixtbl_read() unconditionally accessed the physical table, even
  though the data was only needed in a quarter of all cases
- various calculations were done unnecessarily for both of the rather
  distinct code paths in msixtbl_read()

Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
chosen to be 3.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -157,7 +157,7 @@ struct msixtbl_entry
     struct pci_dev *pdev;
     unsigned long gtable;       /* gpa of msix table */
     unsigned long table_len;
-    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + 1];
+    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
 
     struct rcu_head rcu;
 };
@@ -179,17 +179,14 @@ static struct msixtbl_entry *msixtbl_fin
 static void __iomem *msixtbl_addr_to_virt(
     struct msixtbl_entry *entry, unsigned long addr)
 {
-    int idx, nr_page;
+    unsigned int idx, nr_page;
 
-    if ( !entry )
+    if ( !entry || !entry->pdev )
         return NULL;
 
     nr_page = (addr >> PAGE_SHIFT) -
               (entry->gtable >> PAGE_SHIFT);
 
-    if ( !entry->pdev )
-        return NULL;
-
     idx = entry->pdev->msix_table_idx[nr_page];
     if ( !idx )
         return NULL;
@@ -207,10 +204,10 @@ static int msixtbl_read(
     void *virt;
     int r = X86EMUL_UNHANDLEABLE;
 
-    rcu_read_lock();
+    if ( len != 4 || (address & 3) )
+        return r;
 
-    if ( len != 4 )
-        goto out;
+    rcu_read_lock();
 
     offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
     if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET)
@@ -235,13 +232,13 @@ static int msixtbl_write(struct vcpu *v,
     unsigned long offset;
     struct msixtbl_entry *entry;
     void *virt;
-    int nr_entry;
+    unsigned int nr_entry;
     int r = X86EMUL_UNHANDLEABLE;
 
-    rcu_read_lock();
+    if ( len != 4 || (address & 3) )
+        return r;
 
-    if ( len != 4 )
-        goto out;
+    rcu_read_lock();
 
     entry = msixtbl_find_entry(v, address);
     nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
@@ -261,9 +258,22 @@ static int msixtbl_write(struct vcpu *v,
     if ( !virt )
         goto out;
 
+    /* Do not allow the mask bit to be changed. */
+#if 0 /* XXX
+       * As the mask bit is the only defined bit in the word, and as the
+       * host MSI-X code doesn't preserve the other bits anyway, doing
+       * this is pointless. So for now just discard the write (also
+       * saving us from having to determine the matching irq_desc).
+       */
+    spin_lock_irqsave(&desc->lock, flags);
+    orig = readl(virt);
+    val &= ~PCI_MSIX_VECTOR_BITMASK;
+    val |= orig & PCI_MSIX_VECTOR_BITMASK;
     writel(val, virt);
-    r = X86EMUL_OKAY;
+    spin_unlock_irqrestore(&desc->lock, flags);
+#endif
 
+    r = X86EMUL_OKAY;
 out:
     rcu_read_unlock();
     return r;
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -127,12 +127,6 @@ extern const struct hw_interrupt_type pc
 #define PCI_MSIX_FLAGS_BIRMASK		(7 << 0)
 #define PCI_MSIX_FLAGS_BITMASK		(1 << 0)
 
-#define PCI_MSIX_ENTRY_SIZE			16
-#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
-#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
-#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
-#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
-
 #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
 #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
 #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -11,6 +11,8 @@
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
+#include <xen/pci_regs.h>
+#include <asm/page.h>
 
 /*
  * The PCI interface treats multi-function devices as independent
@@ -29,8 +31,10 @@
 #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
 #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
 
-#define MAX_MSIX_TABLE_ENTRIES  2048
-#define MAX_MSIX_TABLE_PAGES    8
+#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
+#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
+                                       PCI_MSIX_ENTRY_SIZE + \
+                                       (~PCI_MSIX_FLAGS_BIRMASK & (PAGE_SIZE - 1)))
 struct pci_dev_info {
     unsigned is_extfn;
     unsigned is_virtfn;
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -302,6 +302,13 @@
 #define  PCI_MSIX_FLAGS_ENABLE	(1 << 15)
 #define  PCI_MSIX_FLAGS_MASKALL	(1 << 14)
 #define PCI_MSIX_FLAGS_BIRMASK	(7 << 0)
+
+#define PCI_MSIX_ENTRY_SIZE			16
+#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
+#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
+#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
+#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
+
 #define PCI_MSIX_FLAGS_BITMASK	(1 << 0)
 
 /* CompactPCI Hotswap Register */

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

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

Re: backport requests for 4.x-testing

[Keir Fraser]

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
>