date:20190122

On Mon, Jan 21, 2019 at 07:02:25PM +, Andrew Cooper wrote:
> This option is unique to x86 PV dom0's, but it is not sensible to have a
> catch-all which blindly maps all non-RAM regions into the IOMMU.
> 
> The map-reserved option remains, and covers all the buggy firmware issues that
> I am aware of.  The two common cases are legacy USB keyboard emulation, and
> the BMC mailbox used by vendor firmware in NICs/HBAs to report information
> back to the iLO/iDRAC/etc for remote remote management purposes.
> 
> A specific advantage of this change is that x86 dom0's IOMMU setup is now
> consistent between PV and PVH.
> 
> This change is not expected to have any impact, due to map-reserved remaining.
> In the unlikely case that it does cause an issue, we should introduce other
> map-$SPECIFIC options rather than re-introducing this catch-all.
> 
> Signed-off-by: Andrew Cooper 
> Release-acked-by: Juergen Gross 

Reviewed-by: Roger Pau Monné 

Will it be worth printing a warning message in arch_iommu_hwdom_init
about map-inclusive deprecation if it's enabled?

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] drm: Split out drm_probe_helper.h

2019-01-22 Thread Daniel Vetter

On Mon, Jan 21, 2019 at 11:13 PM Sam Ravnborg  wrote:
>
> Hi Daniel et al.
>
> > >
> > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy
> > > kms drivers. Just removing it from all the atomic drivers caused lots of
> > > fallout, I expect even more if you entirely remove the includes it has.
> > > Maybe a todo, care to pls create that patch since it's your idea?
> >
> > The main reason I bailed out initially was that this would create
> > small changes to several otherwise seldomly touched files.
> > And then we would later come and remove drmP.h - so lots of
> > small but incremental changes to the same otherwise seldomly
> > edited files.
> > And the job was only partially done.
> >
> > I will try to experiment with an approach where I clean up the
> > include/drm/*.h files a little (like suggested above, +delete drmP.h
> > and maybe a bit more).
> >
> > Then to try on a driver by driver basis to make it build with a
> > cleaned set of include files.
> > I hope that the cleaned up driver can still build without the
> > cleaned header files so the changes can be submitted piecemal.
> >
> > Will do so with an eye on the lesser maintained drivers to try it
> > out to avoid creating too much chrunch for others.
>
> I have now a few patches queued, but the result is not too pretty.
> I did the following:
>
> - For all files in include/drm/*.h the set of include files
>   were adjusted to the minimum number of files required to make
>   them build without any other files included first.
>
>   Created one .c file for each .h file. Then included the .h
>   file and adjusted to the minimal set of include files.
>   In the process a lot of forwards were added.
>
> - Deleted drmP.h
>
> - Fixed build of a few drivers: sti, tilcdc, gma500, tve200, via
>
> Some observations:
>
> - Killing all the includes not needed in the headers files
>   results in a a lot of extra changes.
>   Examples:
> drm_modseset_helper_vtables.h is no longer
> included by anyone, so needs to be added in many files
>
> drm_atomic_state_helper.h is no longer included
> by anyone so likewise needs to be added in many files
>
> - It is very tedious to do this properly.
>   The process I followed was:
>   - delete / comment out all include files
>   - add back the obvious from a quick scan of the code
>   - build - fix - build - fix - build - fix ...
>   -   next file...
>
> - The result is errorprone as only the allyesconfig + allmodconfig
>   variants are tested. But reallife configurations are more diverse.
>
> Current diffstat:
>111 files changed, 771 insertions(+), 401 deletions(-)
>
> This is for the 5 drivers alone and not the header cleanup.
> So long story short - this is not good and not the way forward.
>
> I will try to come up with a few improvements to make the
> headers files selfcontained, but restricted to the changes that
> add forwards/include to avoid the chrunch in all the drivers.
>
> And then post for review a few patches to clean up some headers.
> If the cleanup gets a go I will try to persuade the introduction
> of these.
> This will include, but will not be limited to, the above mentioned
> drm_crtc_helper.h header file.
>
> For now too much time was already spent on this, so it is at the
> moment pushed back on my TODO list.
> This mail serve also as a kind of "where had I left", when/if I
> pick this up again.
>
> If there are anyone that knows some tooling that can help in the
> process of adjusting the header files I am all ears.

Yeah in the process of splitting up drmP.h we've created a few smaller
such piles of headers. I think in some cases it's just not going to be
worth it to fully split them up, e.g. drm_crtc_helper.h is going to be
a pure legacy helper, only needed by pre-atomic drivers. Splitting
that up doesn't seem to useful to me. Similarly we might want
drm_atomic_helper.h to keep pulling in the other helper headers. So
probably going to be a judgement call on a case-by-case basis.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/2] x86: respect memory size limiting via mem= parameter

When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.

Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added when adding PCI devices due to corresponding ACPI table entries.

Not respecting "mem=" can be corrected by adding a global max_mem_size
variable set by parse_memopt() which will result in rejecting adding
memory areas resulting in a memory size above the allowed limit.

Signed-off-by: Juergen Gross 
---
 arch/x86/kernel/e820.c | 5 +
 include/linux/memory_hotplug.h | 2 ++
 mm/memory_hotplug.c| 6 ++
 3 files changed, 13 insertions(+)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 50895c2f937d..e67513e2cbbb 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -881,6 +882,10 @@ static int __init parse_memopt(char *p)
 
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1);
 
+#ifdef CONFIG_MEMORY_HOTPLUG
+   max_mem_size = mem_size;
+#endif
+
return 0;
 }
 early_param("mem", parse_memopt);
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 07da5c6c5ba0..fb6bd0022d41 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -98,6 +98,8 @@ extern void __online_page_free(struct page *page);
 
 extern int try_online_node(int nid);
 
+extern u64 max_mem_size;
+
 extern bool memhp_auto_online;
 /* If movable_node boot option specified */
 extern bool movable_node_enabled;
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index b9a667d36c55..7fc2a87110a3 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -96,10 +96,16 @@ void mem_hotplug_done(void)
cpus_read_unlock();
 }
 
+u64 max_mem_size = -1;
+
 /* add this memory to iomem resource */
 static struct resource *register_memory_resource(u64 start, u64 size)
 {
struct resource *res, *conflict;
+
+   if (start + size > max_mem_size)
+   return ERR_PTR(-E2BIG);
+
res = kzalloc(sizeof(struct resource), GFP_KERNEL);
if (!res)
return ERR_PTR(-ENOMEM);
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/2] x86: respect memory size limits

On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.

During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
parameter.

The system this problem has been observed on has tons of memory
added via PCI. So while in the E820 map the not to be used memory has
been wiped out the additional PCI memory is detected during ACPI scan
and it is added via __add_memory().

This small series tries to repair the issue by testing the imposed
memory limit during the memory hotplug process and refusing to add it
in case the limit is being violated.

I've chosen to refuse adding the complete memory chunk in case the
limit is reached instead of adding only some of the memory, as I
thought this would result in less problems (e.g. avoiding to add
only parts of a 128MB memory bar which might be difficult to remove
later).


Juergen Gross (2):
  x86: respect memory size limiting via mem= parameter
  x86/xen: dont add memory above max allowed allocation

 arch/x86/kernel/e820.c | 5 +
 arch/x86/xen/setup.c   | 5 +
 include/linux/memory_hotplug.h | 2 ++
 mm/memory_hotplug.c| 6 ++
 4 files changed, 18 insertions(+)

-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/2] x86/xen: dont add memory above max allowed allocation

Don't allow memory to be added above the allowed maximum allocation
limit set by Xen.

Trying to do so would result in cases like the following:

[  584.559652] [ cut here ]
[  584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129 
xen_alloc_pte+0x1c7/0x390()
[  584.575151] Modules linked in:
[  584.578643] Supported: Yes
[  584.581750] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.120-92.70-default 
#1
[  584.59] Hardware name: Cisco Systems Inc UCSC-C460-M4/UCSC-C460-M4, BIOS 
C460M4.4.0.1b.0.0629181419 06/29/2018
[  584.601862]   813175a0  
8184777c
[  584.610200]  8107f4e1 880487eb7000 8801862b79c0 
88048608d290
[  584.618537]  00487eb7 ea000201 81009de7 
81068561
[  584.626876] Call Trace:
[  584.629699]  [] dump_trace+0x59/0x340
[  584.635645]  [] show_stack_log_lvl+0xea/0x170
[  584.642391]  [] show_stack+0x21/0x40
[  584.648238]  [] dump_stack+0x5c/0x7c
[  584.654085]  [] warn_slowpath_common+0x81/0xb0
[  584.660932]  [] xen_alloc_pte+0x1c7/0x390
[  584.667289]  [] pmd_populate_kernel.constprop.6+0x40/0x80
[  584.675241]  [] phys_pmd_init+0x210/0x255
[  584.681587]  [] phys_pud_init+0x1da/0x247
[  584.687931]  [] kernel_physical_mapping_init+0xf5/0x1d4
[  584.695682]  [] init_memory_mapping+0x18d/0x380
[  584.702631]  [] arch_add_memory+0x59/0xf0

Signed-off-by: Juergen Gross 
---
 arch/x86/xen/setup.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index d5f303c0e656..5929a6ba5c25 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -785,6 +786,10 @@ char * __init xen_memory_setup(void)
/* How many extra pages do we need due to remapping? */
max_pages += xen_foreach_remap_area(max_pfn, xen_count_remap_pages);
 
+#ifdef CONFIG_MEMORY_HOTPLUG
+   max_mem_size = PFN_PHYS(max_pages);
+#endif
+
if (max_pages > max_pfn)
extra_pages += max_pages - max_pfn;
 
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 7/7] xen/dom0: Add a dom0-iommu=none option

>>> On 21.01.19 at 19:08,  wrote:
> On 17/01/2019 13:35, Jan Beulich wrote:
> On 16.01.19 at 10:00,  wrote:
>>> @@ -709,6 +709,12 @@ Controls for the dom0 IOMMU setup.
>>>  This option is enabled by default on x86 systems, and invalid on ARM
>>>  systems.
>>>  
>>> +*   The `none` option is intended for development purposes only, and skips
>>> +certain safety checks pertaining to the correct IOMMU configuration for
>>> +dom0 to boot.
>> Would you mind inserting "PVH" ahead of "dom0"?
> 
> That would result in an inaccurate description of the functionality. 
> check_hwdom_reqs() is not specific to PVH guests.

How is the paging_mode_translate() check your patch actually
amends not making this function effectively PVH-specific? Or
are you meaning to imply that some hypothetical future addition
to the checks affecting PV Dom0 is to be covered here as well?

>>> @@ -156,7 +159,7 @@ int iommu_domain_init(struct domain *d)
>>>  
>>>  static void __hwdom_init check_hwdom_reqs(struct domain *d)
>>>  {
>>> -if ( !paging_mode_translate(d) )
>>> +if ( iommu_hwdom_none || !paging_mode_translate(d) )
>>>  return;
>> Seeing the __hwdom_init, wouldn't it be better to restrict this
>> relaxation to Xen boot time created Dom0?
> 
> No, I don't think so.
> 
> That would complicate the change (which is already only for use by
> developers), and unnecessarily prohibit testing of the late hwdom paths.

Well, I don't fully agree, but okay then. Therefore if the answer
to the second question above is "yes", then
Acked-by: Jan Beulich 

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] iommu: Eliminate an odd local variable

>>> On 21.01.19 at 17:04,  wrote:
> Wipe out excessive lines from an iommu_unmap(), and align it with an
> iommu_map() code.

What's excessive there? How come you alter the function's
return value without saying why? The more that you make
it potentially return success when there was an error.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

>>> On 22.01.19 at 06:50,  wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>>> @@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg, u8 
>>> bus, u8 devfn)
>>>  if ( !pdev )
>>>  return -ENODEV;
>>>  
>>> +pci_unmap_msi(pdev);
>>
>>Just want to make sure, since deassign_device will be called for both
>>PV and HVM domains. AFAICT pci_unmap_msi is safe to call when the
>>device is assigned to a PV guest, but would like your confirmation.
> 
> Tested with a PV guest loaded by Pygrub. PV guest doesn't suffer the
> msi-x issue I want to fix.
> 
> With these three patches applied, I got some error messages from Xen
> and Dom0 as follow:
> 
> (XEN) irq.c:2176: dom3: forcing unbind of pirq 332
> (XEN) irq.c:2176: dom3: forcing unbind of pirq 331
> (XEN) irq.c:2176: dom3: forcing unbind of pirq 328
> (XEN) irq.c:2148: dom3: pirq 359 not mapped
> [ 2887.067685] xen:events: unmap irq failed -22
> (XEN) irq.c:2148: dom3: pirq 358 not mapped
> [ 2887.075917] xen:events: unmap irq failed -22
> (XEN) irq.c:2148: dom3: pirq 357 not mapped
> 
> It seems, the cause of such error is that pirq-s are unmapped and forcibly
> unbound on deassignment; subsequent unmapping pirq issued by dom0 fail.
> From some aspects, this error is expected. Because with this patch,
> pirq-s are expected to be mapped by qemu or dom0 kernel (for pv case) before
> deassignment and mapping/binding pirq after deassignment should fail.
> 
> So what's your opinion on handling such error? We should figure out another
> method to fix msi-x issue to avoid such error or suppress these errors in
> qemu and linux kernel?

The "forcing unbind" ones are probably fine to leave alone, but
the errors would better be avoided in Xen (i.e. without a need
to also change qemu and/or Linux). Since you don't really say
when / why these errors now surface, it's hard to suggest what
might be best to do.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-xl-shadow

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-shadow
testid xen-boot

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  7b8052e19304865477e03a0047062d977309a22f
  Bug not present: d255d18a34a8d53ccc4a019dc07e17b6e8cf6bd1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132328/


  commit 7b8052e19304865477e03a0047062d977309a22f
  Author: Jan Beulich 
  Date:   Mon Oct 19 04:23:29 2015 -0600
  
  igb: fix NULL derefs due to skipped SR-IOV enabling
  
  [ Upstream commit be06998f96ecb93938ad2cce46c4289bf7cf45bc ]
  
  The combined effect of commits 6423fc3416 ("igb: do not re-init SR-IOV
  during probe") and ceee3450b3 ("igb: make sure SR-IOV init uses the
  right number of queues") causes VFs no longer getting set up, leading
  to NULL pointer dereferences due to the adapter's ->vf_data being NULL
  while ->vfs_allocated_count is non-zero. The first commit not only
  neglected the side effect of igb_sriov_reinit() that the second commit
  tried to account for, but also that of setting IGB_FLAG_HAS_MSIX,
  without which igb_enable_sriov() is effectively a no-op. Calling
  igb_{,re}set_interrupt_capability() as done here seems to address this,
  but I'm not sure whether this is better than sinply reverting the other
  two commits.
  
  Signed-off-by: Jan Beulich 
  Tested-by: Aaron Brown 
  Signed-off-by: Jeff Kirsher 
  Signed-off-by: Sasha Levin 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-i386-xl-shadow.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-xl-shadow.xen-boot
 --summary-out=tmp/132328.bisection-summary --basis-template=128858 
--blessings=real,real-bisect linux-3.18 test-amd64-i386-xl-shadow xen-boot
Searching for failure / basis pass:
 132179 fail [host=debina0] / 131580 [host=joubertin0] 131563 [host=italia0] 
131535 [host=albana0] 131512 [host=huxelrebe1] 131479 [host=baroque1] 131442 
[host=huxelrebe0] 131420 [host=fiano0] 131370 [host=rimava1] 131336 
[host=baroque0] 131307 [host=italia0] 131279 [host=pinot0] 131231 
[host=joubertin0] 131192 [host=albana0] 131149 [host=huxelrebe1] 131095 
[host=baroque1] 131035 [host=fiano0] 130939 [host=rimava1] 130876 
[host=italia0] 130843 [host=joubertin0] 130367 [host=italia0] 130203 [host\
 =albana1] 130067 [host=rimava1] 129845 [host=fiano0] 129760 [host=albana0] 
128858 [host=joubertin0] 128841 [host=albana1] 128807 ok.
Failure / basis pass flights: 132179 / 128807
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9b5eed105a45ac0557af113b4096132ae7e3e47f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
93a62c544e20ba9e141e411bbaae3d65259d13a3
Basis pass 0d63979c1bc9c85578be4c589768a13dc0a7c5eb 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#0d63979c1bc9c85578be4c589768a13dc0a7c5eb-9b5eed105a45ac0557af113b4096132ae7e3e47f
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798
 git://xenbits.xen.org/qemu-xen.git\
 
#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986
 
git://xenbits.xen.org/xen.git#92666fdd6e0afab989b2d89759d9b43f2c645ae7-93a62c544e20ba9e141e411bbaae3d65259d13a3
Loaded 3004 nodes in revision graph
Searching for test results:
 128691 [host=huxelrebe0]
 128807 pass 0d63979c1bc9c85578be4c589768a13dc0a7c5eb 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
 128858 [host=joub

Re: [Xen-devel] [PATCH 2/2] x86/xen: dont add memory above max allowed allocation

>>> On 22.01.19 at 09:06,  wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.

This reads as if the hypervisor was imposing a limit here, but looking at
xen_get_max_pages(), xen_foreach_remap_area(), and
xen_count_remap_pages() I take it that it's a restriction enforced by
the Xen subsystem in Linux. Furthermore from the cover letter I imply
that the observed issue was on a Dom0, yet xen_get_max_pages()'s
use of XENMEM_maximum_reservation wouldn't impose any limit there
at all (without use of the hypervisor option "dom0_mem=max:..."),
would it?

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

>>> On 22.01.19 at 00:15,  wrote:
> On Mon, 21 Jan 2019, Jan Beulich wrote:
>> >>> On 21.01.19 at 11:22,  wrote:
>> > Hi Jan,
>> > 
>> > On 21/01/2019 09:34, Jan Beulich wrote:
>> > On 18.01.19 at 11:48,  wrote:
>> >>> On 18/01/2019 09:54, Jan Beulich wrote:
>> >>> On 18.01.19 at 02:24,  wrote:
>> > On Thu, 17 Jan 2019, Jan Beulich wrote:
>> > On 17.01.19 at 01:37,  wrote:
>> >>> On Wed, 16 Jan 2019, Jan Beulich wrote:
>>  Stop. No. We very much can prove they are - _end points at
>>  one past the last element of _start[]. It is the compiler which
>>  can't prove the opposite, and hence it can't leverage
>>  undefined behavior for optimization purposes.
>> >>>
>> >>> You keep saying the compiler can't leverage it for optimization purpose,
>> >>> however
>> >>> there are confirmations that GCC may actually leverage it (e.g [1]). You
>> >>> actually need to trick the compiler to avoid the optimization (e.g
>> >>> RELOC_HIDE).
>> >>>
>> >>> So obviously, this is not only a MISRA "problem" as you state here and
>> >>> below.
>> >>>
>> >>> I believe Stefano, Stewart and I provided plenty of documentation/thread 
>> >>> to
>> >>> support our positions. Can you provide us documentation/thread showing 
>> >>> the
>> >>> compiler will not try to leverage that case?
>> >>>
>> >>> Cheers,
>> >>>
>> >>> [1]
>> >>> 
>> > 
> https://kristerw.blogspot.com/2016/12/pointer-comparison-invalid-optimization.h
>  
> tml?m=1
>> >> 
>> >> Btw., the __start[] / __end[] example given there does not match
>> >> up with what I see.
>> > What you see in a specific version of GCC. This does not mean this 
>> > behavior 
> is 
>> > valid across all the released versions and future one.
>> 
>> Are you suggesting that for the purpose of certification we need to
>> deal with compiler bugs? Imo such a compiler should simply be
>> excluded for use to build Xen.
>> 
>> >> Only symbols defined in the same CU as where
>> >> the comparison sits get "optimized" this way. Externs as well as
>> >> weak symbols defined locally don't get dealt with like this. And how
>> >> could they? Nothing tells the compiler that two distinct symbols
>> >> refer to two distinct objects. It is easy to create objects with
>> >> multiple names, not only in assembly but also in C (using the "alias"
>> >> attribute).
>> > 
>> > Similarly, nothing tells the compiler that they are not two distinct 
> symbols. 
>> > You haven't yet provided evidence a compiler cannot use that for 
> optimization.
>> 
>> The compiler can leverage for optimization only what it can prove
>> (to be undefined behavior or symbols referring to distinct objects
>> or ...). A compiler may never use guesses for optimization. That
>> is in the case here it is not us who need to tell the compiler that
>> two different symbols may refer to the same object, but it is the
>> compiler which needs to prove that two symbols cannot possibly
>> refer to the same object. This is possible for automatic and static
>> objects. This is also possible for some non-static objects defined
>> in the CU under compilation. But this is not possible in the general
>> case.
> 
> Clearly from the GCC thread not everybody agrees with you:
> 
>  Just because two pointers print the same and have the same bit-pattern 
>  doesn't mean they need to compare equal
> 
>  So the only way within the C standard you could deduce that two objects 
>  follow each other in memory is that the address of one compares equal to 
>  one past the address of the other - but that does not mean they follow 
>  each other in memory for any other comparison.

I think continuing to hit on this aspect is just adding confusion: We
_do not_ leverage the "end" labels to happen to point at the end of
the previous object. That's a pattern the subsequent objects' "start"
label may happen to match. The "end" labels, otoh, don't point at
the start of any object, they point at what we point them at - the
end of the preceding object. Once again I'd like to emphasize the
difference between "object" and "symbol"; as said before I have
not been able to find anything in the spec saying that there's a
requirement that symbols can only point at the start of objects, or
that there can only be a single symbol pointing at a given object.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] x86/xen: dont add memory above max allowed allocation

On 22/01/2019 09:52, Jan Beulich wrote:
 On 22.01.19 at 09:06,  wrote:
>> Don't allow memory to be added above the allowed maximum allocation
>> limit set by Xen.
> 
> This reads as if the hypervisor was imposing a limit here, but looking at
> xen_get_max_pages(), xen_foreach_remap_area(), and
> xen_count_remap_pages() I take it that it's a restriction enforced by
> the Xen subsystem in Linux. Furthermore from the cover letter I imply
> that the observed issue was on a Dom0, yet xen_get_max_pages()'s
> use of XENMEM_maximum_reservation wouldn't impose any limit there
> at all (without use of the hypervisor option "dom0_mem=max:..."),
> would it?

Oh yes, you are right, of course!

I need to check the current reservation and adjust the allowed limit
in case of ballooning and/or memory hotplug.

Thanks for noticing that!


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

>>> On 22.01.19 at 00:41,  wrote:
> We haven't managed to reach consensus on this topic. Your view might be
> correct, but it is not necessarily supported by compilers' behavior,
> which depends on the opinion of compilers engineers on the topic, and
> MISRAC compliance, which depends on the opinion of MISRAC specialists on
> the topic. If we take your suggested approach we end up with the code
> most likely to break in case the compilers engineers or the MISRAC
> experts disagree with you. In this case, being right doesn't necessarily
> lead to the code less likely to break.
> 
> Regardless, if that is the decision of the Xen community as a whole,
> I'll follow it. My preference remains with approach 3. (var.S), followed
> by approach 2. (SYMBOL_HIDE returns uintptr_t), but I am willing to
> refresh my series to do approach 1. (SYMBOL_HIDE returns pointer type)
> if that is the only way forward.
> 
> Let us come to a conclusion so that we can move on.

How can we come to a conclusion when things remain unclear? I see
only two ways forward - either we settle the dispute (which I'm
afraid would require involvement of someone accepted by all of us
as a "C language lawyer", which would include judgment about the
MISRA-C implications), or you request a vote, by which my
objection to _any_ change here without proper justification can be
outvoted. Only at that point can we then decide whether any of
the proposed "solutions" (in quotes because I remain unconvinced
there's a problem to solve here other than working around compiler
bugs) is/are necessary _and_ fulfilling the purpose, and if multiple
remain, which of them we like best / is the least bad one.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

On Tue, Jan 22, 2019 at 01:50:20PM +0800, Chao Gao wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> >> +}
> >> +}
> >> +/*
> >> + * All pirq-s should have been unmapped and corresponding msi_desc
> >> + * entries should have been removed in the above loop.
> >> + */
> >> +ASSERT(list_empty(&pdev->msi_list));
> >> +
> >> +spin_unlock(&d->event_lock);
> >> +}
> >> +
> >>  /* caller should hold the pcidevs_lock */
> >>  int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
> >>  {
> >> @@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg, u8 
> >> bus, u8 devfn)
> >>  if ( !pdev )
> >>  return -ENODEV;
> >>  
> >> +pci_unmap_msi(pdev);
> >
> >Just want to make sure, since deassign_device will be called for both
> >PV and HVM domains. AFAICT pci_unmap_msi is safe to call when the
> >device is assigned to a PV guest, but would like your confirmation.
> 
> Tested with a PV guest loaded by Pygrub. PV guest doesn't suffer the
> msi-x issue I want to fix.
> 
> With these three patches applied, I got some error messages from Xen
> and Dom0 as follow:
> 
> (XEN) irq.c:2176: dom3: forcing unbind of pirq 332
> (XEN) irq.c:2176: dom3: forcing unbind of pirq 331
> (XEN) irq.c:2176: dom3: forcing unbind of pirq 328
> (XEN) irq.c:2148: dom3: pirq 359 not mapped
> [ 2887.067685] xen:events: unmap irq failed -22
> (XEN) irq.c:2148: dom3: pirq 358 not mapped
> [ 2887.075917] xen:events: unmap irq failed -22
> (XEN) irq.c:2148: dom3: pirq 357 not mapped
> 
> It seems, the cause of such error is that pirq-s are unmapped and forcibly
> unbound on deassignment; subsequent unmapping pirq issued by dom0 fail.
> From some aspects, this error is expected. Because with this patch,
> pirq-s are expected to be mapped by qemu or dom0 kernel (for pv case) before
> deassignment and mapping/binding pirq after deassignment should fail.

This is quite entangled because it involves Xen, libxl and pciback.

AFAICT libxl will already try to unmap the pirqs before deassigning
the device if the domain is PV, see do_pci_remove in libxl_pci.c and
the calls it makes to xc_physdev_unmap_pirq.

Which makes me wonder, have you tested if you see those messages about
pirq unmap failure without this patch applied?

> So what's your opinion on handling such error? We should figure out another
> method to fix msi-x issue to avoid such error or suppress these errors in
> qemu and linux kernel?

Regardless of the reply to the question above, I think
unmap_domain_pirq should return ESRCH if the pirq cannot be found,
like the patch below. That would turn the Linux kernel messages into
less scary info messages, like:

"domain %d does not have %d anymore"

Which seems more accurate.

Thanks, Roger.

---8<---
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 23b4f423e6..7e9c974ba1 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2144,9 +2144,9 @@ int unmap_domain_pirq(struct domain *d, int pirq)
 info = pirq_info(d, pirq);
 if ( !info || (irq = info->arch.irq) <= 0 )
 {
-dprintk(XENLOG_G_ERR, "dom%d: pirq %d not mapped\n",
+dprintk(XENLOG_G_INFO, "dom%d: pirq %d not mapped\n",
 d->domain_id, pirq);
-ret = -EINVAL;
+ret = -ESRCH;
 goto done;
 }
 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] iommu: Eliminate an odd local variable


Hello Jan,

On 22.01.19 10:20, Jan Beulich wrote:

What's excessive there? How come you alter the function's
return value without saying why? The more that you make
it potentially return success when there was an error.


Ah, I've realized the difference. In unmap, for hardware domain, we will 
iterate through pages even if some page failed to unmap, preserving the first 
caught error.
So my patch is wrong.

Sorry for disturbing.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] x86_64 to i386 boot generation conversion

2019-01-22 Thread nicolas . poirot

Hi everyone,

I was wondering why when I build an x86_64 xen I got a mkelf32 command 
converting elf 64 to elf 32.
My understanding, looking at git-log, is that that was needed for 32bits 
bootloaders.

Is that the only reason ? Is it still necessary today ?

Thanks.

Nicolas 
.


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 07/15] argo: implement the register op

On Mon, Jan 21, 2019 at 01:59:47AM -0800, Christopher Clark wrote:
> The register op is used by a domain to register a region of memory for
> receiving messages from either a specified other domain, or, if specifying a
> wildcard, any domain.
> 
> This operation creates a mapping within Xen's private address space that
> will remain resident for the lifetime of the ring. In subsequent commits,
> the hypervisor will use this mapping to copy data from a sending domain into
> this registered ring, making it accessible to the domain that registered the
> ring to receive data.
> 
> Wildcard any-sender rings are default disabled and registration will be
> refused with EPERM unless they have been specifically enabled with the
> new mac-permissive flag that is added to the argo boot option here. The
> reason why the default for wildcard rings is 'deny' is that there is
> currently no means to protect the ring from DoS by a noisy domain
> spamming the ring, affecting other domains ability to send to it. This
> will be addressed with XSM policy controls in subsequent work.
> 
> Since denying access to any-sender rings is a significant functional
> constraint, the new option "mac-permissive" for the argo bootparam
> enables overriding this. eg: "argo=1,mac-permissive=1"
> 
> The p2m type of the memory supplied by the guest for the ring must be
> p2m_ram_rw and the memory will be pinned as PGT_writable_page while the ring
> is registered.
> 
> xen_argo_gfn_t type is defined and is 64-bit on all architectures which
> assists with avoiding the need for compat code to translate hypercall args.
> This hypercall op and its interface currently only supports 4K-sized pages.
> 
> Signed-off-by: Christopher Clark 

Reviewed-by: Roger Pau Mooné 

Just some nits that can be taken care of later.

> +static int
> +find_ring_mfns(struct domain *d, struct argo_ring_info *ring_info,
> +   const unsigned int npage,
> +   XEN_GUEST_HANDLE_PARAM(xen_argo_gfn_t) gfn_hnd,
> +   const unsigned int len)
> +{
> +unsigned int i;
> +int ret = 0;
> +mfn_t *mfns;
> +void **mfn_mapping;
> +
> +ASSERT(LOCKING_Write_rings_L2(d));
> +
> +if ( ring_info->mfns )
> +{
> +/* Ring already existed: drop the previous mapping. */
> +gprintk(XENLOG_INFO, "argo: vm%u re-register existing ring "
> +"(vm%u:%x vm%u) clears mapping\n",
> +d->domain_id, ring_info->id.domain_id,
> +ring_info->id.aport, ring_info->id.partner_id);
> +
> +ring_remove_mfns(d, ring_info);
> +ASSERT(!ring_info->mfns);
> +}
> +
> +mfns = xmalloc_array(mfn_t, npage);
> +if ( !mfns )
> +return -ENOMEM;
> +
> +for ( i = 0; i < npage; i++ )
> +mfns[i] = INVALID_MFN;
> +
> +mfn_mapping = xzalloc_array(void *, npage);
> +if ( !mfn_mapping )
> +{
> +xfree(mfns);
> +return -ENOMEM;
> +}
> +
> +ring_info->mfns = mfns;
> +ring_info->mfn_mapping = mfn_mapping;
> +
> +for ( i = 0; i < npage; i++ )
> +{
> +xen_argo_gfn_t argo_gfn;
> +mfn_t mfn;
> +
> +ret = __copy_from_guest_offset(&argo_gfn, gfn_hnd, i, 1) ? -EFAULT : 
> 0;
> +if ( ret )
> +break;
> +
> +ret = find_ring_mfn(d, _gfn(argo_gfn), &mfn);
> +if ( ret )
> +{
> +gprintk(XENLOG_ERR, "argo: vm%u: invalid gfn %"PRI_gfn" "
> +"r:(vm%u:%x vm%u) %p %u/%u\n",
> +d->domain_id, gfn_x(_gfn(argo_gfn)),
> +ring_info->id.domain_id, ring_info->id.aport,
> +ring_info->id.partner_id, ring_info, i, npage);
> +break;
> +}
> +
> +ring_info->mfns[i] = mfn;
> +
> +argo_dprintk("%u: %"PRI_gfn" -> %"PRI_mfn"\n",
> + i, gfn_x(_gfn(argo_gfn)), mfn_x(ring_info->mfns[i]));
> +}
> +
> +ring_info->nmfns = i;
> +
> +if ( ret )
> +ring_remove_mfns(d, ring_info);
> +else
> +{
> +ASSERT(ring_info->nmfns == NPAGES_RING(len));
> +
> +gprintk(XENLOG_DEBUG, "argo: vm%u ring (vm%u:%x vm%u) %p "

Nit: this likely wants to be an argo_dprintk?

> +"mfn_mapping %p len %u nmfns %u\n",
> +d->domain_id, ring_info->id.domain_id,
> +ring_info->id.aport, ring_info->id.partner_id, ring_info,
> +ring_info->mfn_mapping, ring_info->len, ring_info->nmfns);
> +}
> +
> +return ret;
> +}
> +
> +static long
> +register_ring(struct domain *currd,
> +  XEN_GUEST_HANDLE_PARAM(xen_argo_register_ring_t) reg_hnd,
> +  XEN_GUEST_HANDLE_PARAM(xen_argo_gfn_t) gfn_hnd,
> +  unsigned int npage, bool fail_exist)
> +{
> +xen_argo_register_ring_t reg;
> +struct argo_ring_id ring_id;
> +void *map_ringp;
> +xen_argo_ring_t *ringp;
> +struct argo_ring_info *ring_info, *new_ring_info = NULL;
> +struct argo_send

Re: [Xen-devel] x86_64 to i386 boot generation conversion

On Tue, Jan 22, 2019 at 10:43:11AM +0100, nicolas.poi...@bertin.fr wrote:
> Hi everyone,
> 
> I was wondering why when I build an x86_64 xen I got a mkelf32 command 
> converting elf 64 to elf 32.
> My understanding, looking at git-log, is that that was needed for 32bits 
> bootloaders.
> 
> Is that the only reason ? Is it still necessary today ?

The original multiboot specification [0] only deals with 32bit
addresses, so the elf headers need to be 32 bits for multiboot to be
able to load it. The more that the kernel is started in protected
mode, so addresses must be below the 4G boundary or else loading or
jumping into the entry point would fail.

Roger.

[0] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] docs: Fix all links to Xen man pages in html

2019-01-22 Thread Anthony PERARD

On Wed, Jan 16, 2019 at 04:16:56PM +, Anthony PERARD wrote:
> Second try, this time also works for all links to xen-vbd-interface(7).
> 
> We don't try anymore to have pod2html generate relative links, instead
> we do it ourself.
> 
> First, we modify all links to man pages to have what looks like an
> absolute URL and pod2html will just write it in the html output.
> Absolute URL in POD are in the form L so let's just use
> a scheme that isn't real, but easy to find in the resulting html output:
> "relative:".
> 
> Then we fix the output and remove all the bogus scheme "relative" and
> can end up with nice relative links.
> 
> Signed-off-by: Anthony PERARD 
> Acked-by: Ian Jackson 

Juergen, could you release-ack this patch and the following one[1]?

Thanks,

[1] xen: Highlight reference in xl-disk-configuration(5)

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent

2019-01-22 Thread Oleksandr Andrushchenko

Hello, Julien!

On 1/21/19 7:09 PM, Julien Grall wrote:
> Hello,
>
> On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
>> On 1/18/19 1:43 PM, Julien Grall wrote:
>>> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
 On 1/17/19 11:18 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 06:43:29AM +, Oleksandr Andrushchenko
> wrote:
>>> This whole issue keeps getting more and more confusing.
>> Well, I don't really do DMA here, but instead the buffers in
>> question are shared with other Xen domain, so effectively it
>> could be thought of some sort of DMA here, where the "device" is
>> that remote domain. If the buffers are not flushed then the
>> remote part sees some inconsistency which in my case results
>> in artifacts on screen while displaying the buffers.
>> When buffers are allocated via DMA API then there are no artifacts;
>> if buffers are allocated with shmem + DMA mapping then there are no
>> artifacts as well.
>> The only offending use-case is when I use shmem backed buffers,
>> but do not flush them
> The right answer would be to implement cache maintainance hooks for
> this case in the Xen arch code.  These would basically look the same
> as the low-level cache maintainance used by the DMA ops, but without
> going through the DMA mapping layer, in fact they should probably
> reuse the same low-level assembly routines.
>
> I don't think this is the first usage of such Xen buffer sharing, so
> what do the other users do?
 I'll have to get even deeper into it. Initially I
 looked at the code, but didn't find anything useful.
 Or maybe I have just overlooked obvious things there
>>>  From Xen on Arm ABI:
>>>
>>> "All memory which is shared with other entities in the system
>>> (including the hypervisor and other guests) must reside in memory
>>> which is mapped as Normal Inner Write-Back Outer Write-Back
>>> Inner-Shareable.
>>> This applies to:
>>>    - hypercall arguments passed via a pointer to guest memory.
>>>    - memory shared via the grant table mechanism (including PV I/O
>>>  rings etc).
>>>    - memory shared with the hypervisor (struct shared_info, struct
>>>  vcpu_info, the grant table, etc).
>>> "
>>>
>>> So you should not need any cache maintenance here. Can you provide
>>> more details on the memory attribute you use for memory shared in both
>>> the backend and frontend?
>>>
>> It takes quite some time to collect this (because many components are
>> involved in the
>> use-case), but for now the pages in the guest domain are:
>> !PTE_RDONLY + PTE_PXN + PTE_SHARED + PTE_AF + PTE_UXN +
>> PTE_ATTRINDX(MT_NORMAL)
>
> So that's the attribute for the page mapped in the frontend, right? 
> How about the backend side?
Please see below
>
> Also, could that page be handed to the graphic card correctly?
Yes, if we use zero-copying. But please see below
> If so, is your graphic card coherent?
Yes, it is
>
> If one of your components is mapping with non-cacheable attributes 
> then you are already not following the Xen Arm ABI. In that case, we 
> would need to discuss how to extend the ABI.
>
> Cheers,
>
Well, I didn't get the attributes of pages at the backend side, but IMO 
those
do not matter in my use-case (for simplicity I am not using zero-copying at
backend side):

1. Frontend device allocates display buffer pages which come from shmem
and have these attributes:
!PTE_RDONLY + PTE_PXN + PTE_SHARED + PTE_AF + PTE_UXN + 
PTE_ATTRINDX(MT_NORMAL)

2. Frontend grants references to these pages and shares those with the 
backend

3. Backend is a user-space application (Weston client), so it uses 
gntdev kernel
driver to mmap the pages. The pages, which are used by gntdev, are those 
coming
from the Xen balloon driver and I believe they are all normal memory and
shouldn't be non-cached.

4. Once the frontend starts displaying it flips the buffers and backend 
does *memcpy*
from the frontend-backend shared buffer into Weston's buffer. This means
no HW at the backend side touches the shared buffer.

5. I can see distorted picture.

Previously I used setup with zero-copying, so then the picture becomes 
more complicated
in terms of buffers and how those used by the backed, but anyways it 
seems that the
very basic scenario with memory copying doesn't work for me.

Using DMA API on frontend's side does help - no artifacts are seen.
This is why I'm thinking that this is related to frontend/kernel side 
rather then to
the backend side. This is why I'm thinking this is related to caches and 
trying to figure
out what can be done here instead of using DMA API.

Thank you,
Olkesandr
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] iommu: specify page_count rather than page_order to iommu_map/unmap()...

>>> On 21.01.19 at 14:22,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 21 January 2019 12:05
>> To: Paul Durrant 
>> Cc: Julien Grall ; Andrew Cooper
>> ; George Dunlap ; Ian
>> Jackson ; Roger Pau Monne ;
>> Wei Liu ; Sander Eikelenboom ;
>> Chao Gao ; Jun Nakajima ;
>> Kevin Tian ; Stefano Stabellini
>> ; xen-devel ;
>> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>> 
>> Subject: RE: [PATCH] iommu: specify page_count rather than page_order to
>> iommu_map/unmap()...
>> 
>> >>> On 21.01.19 at 12:56,  wrote:
>> >>  -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 21 January 2019 11:28
>> >> To: Paul Durrant 
>> >> Cc: Julien Grall ; Andrew Cooper
>> >> ; Roger Pau Monne ;
>> Wei
>> >> Liu ; Sander Eikelenboom ;
>> >> George Dunlap ; Ian Jackson
>> >> ; Chao Gao ; Jun Nakajima
>> >> ; Kevin Tian ; Stefano
>> >> Stabellini ; xen-devel > >> de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
>> >> ; Tim (Xen.org) 
>> >> Subject: Re: [PATCH] iommu: specify page_count rather than page_order
>> to
>> >> iommu_map/unmap()...
>> >>
>> >> >>> On 18.01.19 at 17:03,  wrote:
>> >> > ...and remove alignment assertions.
>> >> >
>> >> > Testing shows that certain callers of iommu_legacy_map/unmap()
>> specify
>> >> > order > 0 ranges that are not order aligned thus causing one of the
>> >> > IS_ALIGNED() assertions to fire.
>> >>
>> >> As said before - without a much better explanation of why the current
>> >> order-based model is unsuitable (so far I've been provided only vague
>> >> pointers into "somewhere in PVH Dom0 boot code" iirc) to understand
>> >> why it's undesirable to simply make those call sites obey to the
>> current
>> >> requirements, I'm not happy to see us go this route.
>> >
>> > I thought...
>> >
>> > "Using a count actually makes more sense because the valid
>> > set of mapping orders is specific to the IOMMU implementation and to it
>> > should be up to the implementation specific code to translate a mapping
>> > count into an optimal set of mapping orders (when the code is finally
>> > modified to support orders > 0)."
>> >
>> > ...was reasonably clear. Is that not a reasonable justification? What
>> else
>> > could I say?
>> 
>> Well, I was hoping to be pointed at the (apparently multiple) call sites
>> where making them match the current function pattern is more involved
>> and/or less desirable than changing the functions here.
> 
> AFAICT, one of them is memory.c:populate_physmap() where the extent order 
> comes from the memop_args and the memory comes from alloc_domheap_pages(), 
> which I don't believe aligns memory on the specified order.

Of course it does (in MFN space). What I notice is that the gpfn passed
in is not validated to be suitably aligned for the specified order. With
guest_physmap_add_entry() processing each 4k page separately this
doesn't currently have any bad effects, but I think it's a bug
nevertheless. After all the comment in struct xen_memory_reservation's
declaration says "size/alignment of each". The issue with fixing flaws
like this is that there's always the risk of causing regressions with
existing guests.

> Regardless of the 
> alignment though, the fact that order comes from a hypercall argument and may 
> not match any of the orders supported by the IOMMU implementation makes me 
> think that using a page count is better.

Splitting up guest requests is orthogonal to whether a count or an
order is more suitable as a parameter.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] arm: gic-v3: clear GICR active interrupts

2019-01-22 Thread Julien Grall


Hi Peng,

The commit title is a bit confusing. It suggests that all interrupts 
should be deactivated at boot, however you are only deactivating the SGIs.


On 1/22/19 2:35 AM, Peng Fan wrote:

On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because hardware design.


What do you mean by hardware design? Is it a defect?



The gic-v3 controller is configured with EOImode to 1, so during xen
reboot, GIC_SGI_CALL_FUNCTION interrupt from CPU0 to other CPUs, but
stop_cpu never return, that means other CPUs have no chance to
deactive the interrupt. During xen booting again, CPU0 will issue
GIC_SGI_CALL_FUNCTION to other CPUs. Because GIC_SGI_CALL_FUNCTION of
other CPUs are active during the last reboot, interrupts could not be
triggered unless we deactive the interrupt first.


From the description here, I think it not very sane to go to sleep with 
an interrupt activate.


A better solution would be to move the deactivation earlier on in do_sgi 
(maybe after eoi_irq) so we call stop_cpu() with all interrupts disabled.




So let's deactive the interrupts during GICv3 initialization to fix


s/deactivate/


this issue.


Similarly to the commit title, you wrote the commit message very 
generically.





Signed-off-by: Peng Fan 
---
  xen/arch/arm/gic-v3.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 6fbc106757..643d4a33f0 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -824,8 +824,12 @@ static int gicv3_cpu_init(void)
  priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
  GIC_PRI_IPI);
  for (i = 0; i < NR_GIC_SGI; i += 4)
+{
  writel_relaxed(priority,
  GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + (i / 4) * 4);
+writel_relaxed(0x,
+GICD_RDIST_SGI_BASE + GICR_ICACTIVER0 + (i / 4) * 4);
+}
  
  priority = (GIC_PRI_IRQ << 24 | GIC_PRI_IRQ << 16 | GIC_PRI_IRQ << 8 |

  GIC_PRI_IRQ);



Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 08/15] argo: implement the unregister op

On Mon, Jan 21, 2019 at 01:59:48AM -0800, Christopher Clark wrote:
> Takes a single argument: a handle to the ring unregistration struct,
> which specifies the port and partner domain id or wildcard.
> 
> The ring's entry is removed from the hashtable of registered rings;
> any entries for pending notifications are removed; and the ring is
> unmapped from Xen's address space.
> 
> If the ring had been registered to communicate with a single specified
> domain (ie. a non-wildcard ring) then the partner domain state is removed
> from the partner domain's argo send_info hash table.
> 
> Signed-off-by: Christopher Clark 

LGTM:

Reviewed-by: Roger Pau Monné 

Just one nit about the open-coded list_for_each.

> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index a7ec0e0..e4cd446 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -43,6 +43,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_addr_t);
>  DEFINE_XEN_GUEST_HANDLE(xen_argo_gfn_t);
>  DEFINE_XEN_GUEST_HANDLE(xen_argo_register_ring_t);
>  DEFINE_XEN_GUEST_HANDLE(xen_argo_ring_t);
> +DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
>  
>  static bool __read_mostly opt_argo;
>  static bool __read_mostly opt_argo_mac_permissive;
> @@ -351,6 +352,37 @@ find_ring_info(const struct domain *d, const struct 
> argo_ring_id *id)
>  return NULL;
>  }
>  
> +static struct argo_send_info *
> +find_send_info(const struct domain *d, const struct argo_ring_id *id)
> +{
> +struct list_head *cursor, *bucket;
> +
> +ASSERT(LOCKING_send_L2(d));
> +
> +/* List is not modified here. Search and return the match if found. */
> +bucket = &d->argo->send_hash[hash_index(id)];
> +
> +for ( cursor = bucket->next; cursor != bucket; cursor = cursor->next )

list_for_each

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 15/15] argo: validate hypercall arg structures via compat machinery

>>> On 21.01.19 at 13:03,  wrote:
 On 20.01.19 at 22:18,  wrote:
>> The "no repeated checks" problem also occurs when another separate
>> struct contains a field of a type that has already been checked:
>> whichever CHECK is performed second will break.
>> 
>> eg.
>> typedef struct xen_argo_ring_data_ent
>> {
>> struct xen_argo_addr ring;
>> uint16_t flags;
>> uint16_t pad;
>> uint32_t space_required;
>> uint32_t max_message_size;
>> } xen_argo_ring_data_ent_t;
>> 
>> also has a field of type xen_argo_addr, which produces CHECK_argo_addr,
>> which then fails because that was already tested in
>> CHECK_argo_send_addr.
> 
> Hmm, I think the mcinfo example above contradicts this, because
> struct mcinfo_common is used by multiple other structures.

Due to

CHECK_mcinfo_common;
# undef xen_mcinfo_common
# undef CHECK_mcinfo_common
# define CHECK_mcinfo_common struct mcinfo_common

which I think would be easy enough to use in your case as well
(until we could perhaps get around and address the underlying
issue, albeit it's not really clear to me how that should be done).

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] docs: Fix all links to Xen man pages in html

On 16/01/2019 17:16, Anthony PERARD wrote:
> Second try, this time also works for all links to xen-vbd-interface(7).
> 
> We don't try anymore to have pod2html generate relative links, instead
> we do it ourself.
> 
> First, we modify all links to man pages to have what looks like an
> absolute URL and pod2html will just write it in the html output.
> Absolute URL in POD are in the form L so let's just use
> a scheme that isn't real, but easy to find in the resulting html output:
> "relative:".
> 
> Then we fix the output and remove all the bogus scheme "relative" and
> can end up with nice relative links.
> 
> Signed-off-by: Anthony PERARD 
> Acked-by: Ian Jackson 

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] man: Highlight reference in xl-disk-configuration(5)

On 16/01/2019 17:16, Anthony PERARD wrote:
> Provide a better way to see the link to a different manpage, with simple
> words.
> 
> Suggested-by: Ian Jackson 
> Signed-off-by: Anthony PERARD 
> Acked-by: Ian Jackson 

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] docs: Fix all links to Xen man pages in html

2019-01-22 Thread Wei Liu

On Tue, Jan 22, 2019 at 12:38:36PM +0100, Juergen Gross wrote:
> On 16/01/2019 17:16, Anthony PERARD wrote:
> > Second try, this time also works for all links to xen-vbd-interface(7).
> > 
> > We don't try anymore to have pod2html generate relative links, instead
> > we do it ourself.
> > 
> > First, we modify all links to man pages to have what looks like an
> > absolute URL and pod2html will just write it in the html output.
> > Absolute URL in POD are in the form L so let's just use
> > a scheme that isn't real, but easy to find in the resulting html output:
> > "relative:".
> > 
> > Then we fix the output and remove all the bogus scheme "relative" and
> > can end up with nice relative links.
> > 
> > Signed-off-by: Anthony PERARD 
> > Acked-by: Ian Jackson 
> 
> Release-acked-by: Juergen Gross 

Now pushed. Thanks.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent

2019-01-22 Thread Julien Grall




On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:

Hello, Julien!


Hi,


On 1/21/19 7:09 PM, Julien Grall wrote:
Well, I didn't get the attributes of pages at the backend side, but IMO
those
do not matter in my use-case (for simplicity I am not using zero-copying at
backend side):


They are actually important no matter what is your use case. If you 
access the same physical page with different attributes, then you are 
asking for trouble.


This is why Xen imposes all the pages shared to have their memory 
attributes following some rules. Actually, speaking with Mark R., we may 
want to tight a bit more the attributes.




1. Frontend device allocates display buffer pages which come from shmem
and have these attributes:
!PTE_RDONLY + PTE_PXN + PTE_SHARED + PTE_AF + PTE_UXN +
PTE_ATTRINDX(MT_NORMAL)


My knowledge of Xen DRM is inexistent. However, looking at the code in 
5.0-rc2, I don't seem to find the same attributes. For instance 
xen_drm_front_gem_prime_vmap and gem_mmap_obj are using 
pgprot_writecombine. So it looks like, the mapping will be non-cacheable 
on Arm64.


Can you explain how you came up to these attributes?



2. Frontend grants references to these pages and shares those with the
backend

3. Backend is a user-space application (Weston client), so it uses
gntdev kernel
driver to mmap the pages. The pages, which are used by gntdev, are those
coming
from the Xen balloon driver and I believe they are all normal memory and
shouldn't be non-cached.

4. Once the frontend starts displaying it flips the buffers and backend
does *memcpy*
from the frontend-backend shared buffer into Weston's buffer. This means
no HW at the backend side touches the shared buffer.

5. I can see distorted picture.

Previously I used setup with zero-copying, so then the picture becomes
more complicated
in terms of buffers and how those used by the backed, but anyways it
seems that the
very basic scenario with memory copying doesn't work for me.

Using DMA API on frontend's side does help - no artifacts are seen.
This is why I'm thinking that this is related to frontend/kernel side
rather then to
the backend side. This is why I'm thinking this is related to caches and
trying to figure
out what can be done here instead of using DMA API.


We actually never required to use cache flush in other PV protocol, so I 
still don't understand why the PV DRM should be different here.


To me, it looks like that you are either missing some barriers or the 
memory attributes are not correct.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

On Mon, Jan 21, 2019 at 01:59:49AM -0800, Christopher Clark wrote:
> sendv operation is invoked to perform a synchronous send of buffers
> contained in iovs to a remote domain's registered ring.
> 
> It takes:
>  * A destination address (domid, port) for the ring to send to.
>It performs a most-specific match lookup, to allow for wildcard.
>  * A source address, used to inform the destination of where to reply.
>  * The address of an array of iovs containing the data to send
>  * .. and the length of that array of iovs
>  * and a 32-bit message type, available to communicate message context
>data (eg. kernel-to-kernel, separate from the application data).
> 
> If insufficient space exists in the destination ring, it will return
> -EAGAIN and Xen will notify the caller when sufficient space becomes
> available.
> 
> Accesses to the ring indices are appropriately atomic. The rings are
> mapped into Xen's private address space to write as needed and the
> mappings are retained for later use.
> 
> Notifications are sent to guests via VIRQ and send_guest_global_virq is
> exposed in the change to enable argo to call it. VIRQ_ARGO_MESSAGE is
   ^ VIRQ_ARGO
> claimed from the VIRQ previously reserved for this purpose (#11).
> 
> The VIRQ notification method is used rather than sending events using
> evtchn functions directly because:
> 
> * no current event channel type is an exact fit for the intended
>   behaviour. ECS_IPI is closest, but it disallows migration to
>   other VCPUs which is not necessarily a requirement for Argo.
> 
> * at the point of argo_init, allocation of an event channel is
>   complicated by none of the guest VCPUs being initialized yet
>   and the event channel logic expects that a valid event channel
>   has a present VCPU.

IMO iff you wanted to use event channels those _must_ be setup by the
guest, ie: the guest argo driver would load, allocate an event channel
and then tell the hypervisor about the event channel that should be
used for argo notifications.

> +static int
> +memcpy_to_guest_ring(const struct domain *d, struct argo_ring_info 
> *ring_info,
> + unsigned int offset,
> + const void *src, XEN_GUEST_HANDLE(uint8_t) src_hnd,
> + unsigned int len)
> +{
> +unsigned int mfns_index = offset >> PAGE_SHIFT;
> +void *dst;
> +int ret;
> +unsigned int src_offset = 0;
> +
> +ASSERT(LOCKING_L3(d, ring_info));
> +
> +offset &= ~PAGE_MASK;
> +
> +if ( len + offset > XEN_ARGO_MAX_RING_SIZE )
> +return -EFAULT;
> +
> +while ( len )
> +{
> +unsigned int head_len = (offset + len) > PAGE_SIZE ? PAGE_SIZE - 
> offset
> +   : len;

IMO that would be clearer as:

head_len = min(PAGE_SIZE - offset, len);

But anyway, this should go away when you move to using vmap.

[...]
> +static int
> +ringbuf_insert(const struct domain *d, struct argo_ring_info *ring_info,
> +   const struct argo_ring_id *src_id,
> +   XEN_GUEST_HANDLE_PARAM(xen_argo_iov_t) iovs_hnd,
> +   unsigned long niov, uint32_t message_type,
> +   unsigned long *out_len)
> +{
> +xen_argo_ring_t ring;
> +struct xen_argo_ring_message_header mh = { };
> +int sp, ret;
> +unsigned int len = 0;
> +xen_argo_iov_t iovs[XEN_ARGO_MAXIOV];
> +xen_argo_iov_t *piov;
> +XEN_GUEST_HANDLE(uint8_t) NULL_hnd =
> +   guest_handle_from_param(guest_handle_from_ptr(NULL, uint8_t), 
> uint8_t);
> +
> +ASSERT(LOCKING_L3(d, ring_info));
> +
> +ret = __copy_from_guest(iovs, iovs_hnd, niov) ? -EFAULT : 0;
> +if ( ret )
> +return ret;
> +
> +/*
> + * Obtain the total size of data to transmit -- sets the 'len' variable
> + * -- and sanity check that the iovs conform to size and number limits.
> + * Enforced below: no more than 'len' bytes of guest data
> + * (plus the message header) will be sent in this operation.
> + */
> +ret = iov_count(iovs, niov, &len);
> +if ( ret )
> +return ret;
> +
> +/*
> + * Size bounds check against ring size and static maximum message limit.
> + * The message must not fill the ring; there must be at least one slot
> + * remaining so we can distinguish a full ring from an empty one.
> + */
> +if ( ((ROUNDUP_MESSAGE(len) +
> +sizeof(struct xen_argo_ring_message_header)) >= ring_info->len) 
> ||
> + (len > MAX_ARGO_MESSAGE_SIZE) )

len is already checked to be <= MAX_ARGO_MESSAGE_SIZE in iov_count
where it gets set, this is redundant.

> +return -EMSGSIZE;
> +
> +ret = get_sanitized_ring(d, &ring, ring_info);
> +if ( ret )
> +return ret;
> +
> +argo_dprintk("ring.tx_ptr=%u ring.rx_ptr=%u ring len=%u"
> + " ring_info->tx_ptr=%u\n",
> + ring.tx_ptr, ring.rx_ptr, ring_info->len, 
> r

[Xen-devel] [linux-linus test] 132227: regressions - FAIL

flight 132227 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132227/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pygrub 19 guest-start/debian.repeat fail REGR. vs. 125898

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125898
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125898
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125898
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125898
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux49a57857aeea06ca831043acbb0fa5e0f50602fd
baseline version:
 linux94710cac0ef4ee177a63b5227664b38c95bbf703

Last test of basis   125898  2018-08-13 21:20:55 Z  161 days
Failing since125921  2018-08-15 13:06:56 Z  159 days  128 attempts
Testing same since   132227  2019-01-21 00:34:38 Z1 days1 attempts


4217 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun

[Xen-devel] GFX passthrough of primary graphics card

2019-01-22 Thread Security Developer

Hi there, I'm trying to pass through my primary graphics card, but I have trouble getting it to work. I posted already on xen-users, but no one replied. So I try again on the developers list.I have the latest xen-unstable, and as Dom0 kernel I run 4.20 (also latest from upstream).I have the following scenario:I want to set up my laptop in "kiosk mode" where there is absolutely no graphics in Dom0 and all hardware sits directly in my VM. This VM is Windows at the moment.I have a laptop with an Intel HD graphics card (so just a single
one for the whole platform). I want to hand over this graphics card to the VM as its primary graphics card (no emulation of hardware).I have configured to hide the card from Dom0 and switch off the use of graphics in Dom0 (kernel command line):xen_pciback.hide=(00:02.0) quiet video=vesafb:off,efifb:offMy configuration file has the following parameters set:vga = "none"nographic = 1builder = "hvm"gfx_passthru=1pci=['00:02.0']When I boot the
VM, I see the following errors in dmesg:[  291.884273] resource sanity check: requesting [mem 0x000c-0x000d], which spans more than PCI Bus :00 [mem 0x000c-0x000c3fff window][  291.884278] caller pci_map_rom+0x6a/0x1b0 mapping multiple BARs[  291.884290] pciback :00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x[  291.934147] xen_pciback: vpci: :00:02.0: assign to virtual slot 0[  291.934275] pciback :00:02.0: registering for 2In xl dmesg I see the following:(XEN) d11: bind: m_gsi=16 g_gsi=28 dev=00.00.3 intx=0(d11) HVM Loader(d11) Detected Xen v4.12.0-rc(d11) Xenbus rings @0xfeffc000, event channel 1(d11)
System requested SeaBIOS(d11) CPU speed is 2712 MHz(d11) Relocating guest memory for lowmem MMIO space disabled(XEN) irq.c:374: Dom11 PCI link 0 changed 0 -> 5(d11) PCI-ISA link 0 routed to IRQ5(XEN) irq.c:374: Dom11 PCI link 1 changed 0 -> 10(d11) PCI-ISA link 1 routed to IRQ10(XEN) irq.c:374: Dom11 PCI link 2 changed 0 -> 11(d11) PCI-ISA link 2 routed to IRQ11(XEN) irq.c:374: Dom11 PCI link 3 changed 0 -> 5(d11) PCI-ISA link 3 routed to IRQ5(d11) pci dev 01:3 INTA->IRQ10(d11) pci dev 02:0 INTA->IRQ11(XEN) memory_map:add: dom11 gfn=fdffc mfn=8ff4f nr=3(d11) pci dev 03:0 INTA->IRQ5(d11) RAM in high memory; setting high_mem resource base to 16600(d11) pci dev 03:0 bar 18 size 01000: 0e00c(d11)
pci dev 02:0 bar 14 size 00100: 0f008(XEN) memory_map:add: dom11 gfn=f1000 mfn=eb000 nr=1000(d11) pci dev 03:0 bar 10 size 00100: 0f104(d11) pci dev 03:0 bar 30 size 2: 0f200(d11) pci dev 02:0 bar 10 size 00100: 0c001(d11) pci dev 03:0 bar 20 size 00040: 0c101(XEN) ioport_map:add: dom11 gport=c100 mport=e000 nr=40(d11) pci dev 01:1 bar 20 size 00010: 0c141(d11) Multiprocessor initialisation:(d11)  - CPU0 ... 39-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.(d11)  - CPU1 ... 39-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.(d11) Testing HVM environment:(d11) Using scratch memory at 40(d11)  - REP INSB across page boundaries ... passed(d11)  - REP INSW
across page boundaries ... passed(d11)  - GS base MSRs and SWAPGS ... passed(d11) Passed 3 of 3 tests(d11) Writing SMBIOS tables ...(d11) Loading SeaBIOS ...(d11) Creating MP tables ...(d11) Loading ACPI ...(d11) vm86 TSS at fc00a680(d11) BIOS map:(d11)  1-100e3: Scratch space(d11)  c-f: Main BIOS(d11) E820 table:(d11)  [00]: : - :000a: RAM(d11)  HOLE: :000a - :000c(d11)  [01]: :000c - :0010: RESERVED(d11)  [02]: :0010 - :9a00: RAM(d11)  [03]: :9a00 - :9c80: RESERVED(d11)  HOLE: :9c80 - :fc00(d11) 
[04]: :fc00 - :fdffc000: RESERVED(d11)  [05]: :fdffc000 - :fdfff000: NVS(d11)  [06]: :fdfff000 - 0001:: RESERVED(d11)  [07]: 0001: - 0001:6600: RAM(d11) Invoking SeaBIOS ...(d11) SeaBIOS (version rel-1.12.0-0-ga698c89-Xen)(d11) BUILD: gcc: (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) binutils: version 2.31.1-15.fc29(d11) (d11) Found Xen hypervisor signature at 4000(d11) Running on QEMU (i440fx)(d11) xen: copy e820...(d11) Relocating init from 0x000d87c0 to 0x99fac360 (size 80896)(d11) Found 6 PCI devices (max PCI bus is 00)(d11) Allocated Xen hypercall page at 99fff000(d11) Detected Xen v4.12.0-rc(d11) xen: copy BIOS tables...(d11)
Copying SMBIOS entry point from 0x00010020 to 0x000f5be0(d11) Copying MPTABLE from 0xfc001180/fc001190 to 0x000f5ae0(d11) Copying PIR from 0x00010040 to 0x000f5a60(d11) Copying ACPI RSDP from 0x000100c0 to 0x000f5a30(d11) Using pmtimer, ioport 0xb008(d11) WARNING - Timeout at wait_reg8:81!(d11) Scan for VGA option rom(XEN) memory_map:add: dom11 gfn=f2000 mfn=c0 nr=20(XEN) memory_map:remove: dom11 gfn=f2000 mfn=c0 nr=20(d11) Turning on vga text mode console(d11) SeaBIOS (version rel-1.12.0-0-ga698c89-Xen)(d11) Machine UUID 89

Re: [Xen-devel] [PATCH v2] gic-vgic: skip irqs locking in gic_restore_pending_irqs()




On 21.01.19 19:40, Julien Grall wrote:

Reviewed-by: Julien Grall 

I will queue this patch for 4.13.


Thank you.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] gic: drop interrupts enabling on interrupts processing


Hello Julien,

On 21.01.19 19:39, Julien Grall wrote:

I think it would make sense to keep the interrupts disabled in is_lpi as well. 
So we keep the behavior the same accross all interrupts.

Agree.
Will send v2 a bit later.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 7/7] xen/dom0: Add a dom0-iommu=none option

2019-01-22 Thread Andrew Cooper

On 22/01/2019 08:06, Jan Beulich wrote:
 On 21.01.19 at 19:08,  wrote:
>> On 17/01/2019 13:35, Jan Beulich wrote:
>> On 16.01.19 at 10:00,  wrote:
 @@ -709,6 +709,12 @@ Controls for the dom0 IOMMU setup.
  This option is enabled by default on x86 systems, and invalid on ARM
  systems.
  
 +*   The `none` option is intended for development purposes only, and skips
 +certain safety checks pertaining to the correct IOMMU configuration 
 for
 +dom0 to boot.
>>> Would you mind inserting "PVH" ahead of "dom0"?
>> That would result in an inaccurate description of the functionality. 
>> check_hwdom_reqs() is not specific to PVH guests.
> How is the paging_mode_translate() check your patch actually
> amends not making this function effectively PVH-specific? Or
> are you meaning to imply that some hypothetical future addition
> to the checks affecting PV Dom0 is to be covered here as well?

I expect it is far more likely that the paging_mode_translate() check be
adjusted in the future, than the caller to be modified to exclude PV guests.

>
 @@ -156,7 +159,7 @@ int iommu_domain_init(struct domain *d)
  
  static void __hwdom_init check_hwdom_reqs(struct domain *d)
  {
 -if ( !paging_mode_translate(d) )
 +if ( iommu_hwdom_none || !paging_mode_translate(d) )
  return;
>>> Seeing the __hwdom_init, wouldn't it be better to restrict this
>>> relaxation to Xen boot time created Dom0?
>> No, I don't think so.
>>
>> That would complicate the change (which is already only for use by
>> developers), and unnecessarily prohibit testing of the late hwdom paths.
> Well, I don't fully agree, but okay then. Therefore if the answer
> to the second question above is "yes", then
> Acked-by: Jan Beulich 

Thanks,

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/2] Dangling fixes for ARM iommu

Hello Julien,

On 21.01.19 19:29, Julien Grall wrote:

(+ Juergen)
All patches candidate for Xen 4.12 should have the release manager CCed and
explain the pros/cons to have those patches for this release. It is also useful
if you add for-4.12 (or similar) in the [...] so we can prioritize it.

I've got the point. Thank you for adding Juergen.

Indeed code base evolved, for instance iommu_use_hap_pt has a slight different
behavior now.

Actually you properly pointed the problem. I'm not sure how it happened,
because I did test build and run for those patches yesterday. But now,
progressing with our stuff porting, I realized that the patch 1 is missing
dependency on `xen/sched.h` required by `iommu_use_hap_pt`.

So please stripped my RB

OK.

The AB is arguable as it is quite old.

I could drop it for v2.

Secondly, it often happens that some patches have the required acked-by and reviewed-by but are not merged because they makes little sense without the rest of the series.

Yes, sure, but fixes are still relevant and are quite autonomous. The only
relation to the series is that they were discovered during its implementation.

In that case, the current code base does not support the case where the P2M is
not shared with the IOMMU and does not support new IOMMU bindings in the
current setup.

It is the intention of the rest of the series.

So I am not convinced they should be included in Xen 4.12 or even without the
rest of the series.

IMO, the pure fixes, like patch 2, and the first hunk of patch 1 should be OK
for 4.12.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 10/15] argo: implement the notify op

On Mon, Jan 21, 2019 at 01:59:50AM -0800, Christopher Clark wrote:
> Queries for data about space availability in registered rings and
> causes notification to be sent when space has become available.
> 
> The hypercall op populates a supplied data structure with information about
> ring state and if insufficient space is currently available in a given ring,
> the hypervisor will record the domain's expressed interest and notify it
> when it observes that space has become available.
> 
> Checks for free space occur when this notify op is invoked, so it may be
> intentionally invoked with no data structure to populate
> (ie. a NULL argument) to trigger such a check and consequent notifications.
> 
> Limit the maximum number of notify requests in a single operation to a
> simple fixed limit of 256.
> 
> Signed-off-by: Christopher Clark 

LGTM, but I would like to see the open-coded versions of the list_
macros fixed:

Reviewed-by: Roger Pau Monné 

> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index 518aff7..4b43bdd 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
[...]
> +static void
> +pending_notify(struct list_head *to_notify)
> +{
> +ASSERT(LOCKING_Read_L1);
> +
> +/* Sending signals for all ents in this list, draining until it is 
> empty. */
> +while ( !list_empty(to_notify) )
> +{
> +struct pending_ent *ent =
> +list_entry(to_notify->next, struct pending_ent, node);

list_first_entry_or_null

> +
> +list_del(&ent->node);
> +signal_domid(ent->domain_id);
> +xfree(ent);
> +}
> +}
> +
> +static void
> +pending_find(const struct domain *d, struct argo_ring_info *ring_info,
> + unsigned int payload_space, struct list_head *to_notify)
> +{
> +struct list_head *cursor, *pending_head;
> +
> +ASSERT(LOCKING_Read_rings_L2(d));
> +
> +/*
> + * TODO: Current policy here is to signal _all_ of the waiting domains
> + *   interested in sending a message of size less than payload_space.
> + *
> + * This is likely to be suboptimal, since once one of them has added
> + * their message to the ring, there may well be insufficient room
> + * available for any of the others to transmit, meaning that they were
> + * woken in vain, which created extra work just to requeue their wait.
> + *
> + * Retain this simple policy for now since it at least avoids starving a
> + * domain of available space notifications because of a policy that only
> + * notified other domains instead. Improvement may be possible;
> + * investigation required.
> + */
> +spin_lock(&ring_info->L3_lock);
> +
> +/* Remove matching ents from the ring list, and add them to "to_notify" 
> */
> +pending_head = &ring_info->pending;
> +cursor = pending_head->next;
> +
> +while ( cursor != pending_head )
> +{
> +struct pending_ent *ent = list_entry(cursor, struct pending_ent, 
> node);
> +
> +cursor = cursor->next;

list_for_each_entry_safe?

> +
> +if ( payload_space >= ent->len )
> +{
> +if ( ring_info->id.partner_id == XEN_ARGO_DOMID_ANY )
> +wildcard_pending_list_remove(ent->domain_id, ent);
> +
> +list_del(&ent->node);
> +ring_info->npending--;
> +list_add(&ent->node, to_notify);
> +}
> +}
> +
> +spin_unlock(&ring_info->L3_lock);
> +}
> +
>  static int
>  pending_queue(const struct domain *d, struct argo_ring_info *ring_info,
>domid_t src_id, unsigned int len)
> @@ -1023,6 +1163,36 @@ pending_requeue(const struct domain *d, struct 
> argo_ring_info *ring_info,
>  }
>  
>  static void
> +pending_cancel(const struct domain *d, struct argo_ring_info *ring_info,
> +   domid_t src_id)
> +{
> +struct list_head *cursor, *pending_head;
> +
> +ASSERT(LOCKING_L3(d, ring_info));
> +
> +/* Remove all ents where domain_id matches src_id from the ring's list. 
> */
> +pending_head = &ring_info->pending;
> +cursor = pending_head->next;
> +
> +while ( cursor != pending_head )
> +{
> +struct pending_ent *ent = list_entry(cursor, struct pending_ent, 
> node);
> +
> +cursor = cursor->next;

list_for_each_entry_safe

> +
> +if ( ent->domain_id == src_id )
> +{
> +/* For wildcard rings, remove each from their wildcard list too. 
> */
> +if ( ring_info->id.partner_id == XEN_ARGO_DOMID_ANY )
> +wildcard_pending_list_remove(ent->domain_id, ent);
> +list_del(&ent->node);
> +xfree(ent);
> +ring_info->npending--;
> +}
> +}
> +}
> +
> +static void
>  wildcard_rings_pending_remove(struct domain *d)
>  {
>  struct list_head *wildcard_head;
> @@ -1158,6 +1328,86 @@ partner_rings_remove(struct domain *src_d)
>  }
>  
>  static int
> +fill_ring_data(const struct domain *currd,
> +   XEN_GUEST_HANDLE(xen_arg

Re: [Xen-devel] [PATCH v5 00/15] Argo: hypervisor-mediated interdomain communication

On Mon, Jan 21, 2019 at 01:59:40AM -0800, Christopher Clark wrote:
> Version five of this patch series:
> 
> * Changes are primarily addressing feedback from the v4 series reviews.
>   Many points noted on the invididual commit posts.
> 
> * Critical sections have been shrunk, with allocations and frees
>   pulled outside where possible, reordering logic within hypercall ops.
> 
> * A new ring hash function implemented, derived from the djb2 string
>   hash function.
> 
> * Flags returned by the notify op have been simplified.
> 
> * Now uses a single argo boot parameter, taking a list:
>   - top level boolean to enable/disable Argo
>   - mac-permissive option to enable/disable wildcard rings
>   - command line doc edit: no "CONFIG_ARGO" but refers to build config
> 
> * Switched to use the standard list data structures used by Xen's
>   common code.

AFAIK this was not requested by any reviewer, so I wonder why you made
such change. The more that you open coded some of the list_ macros
instead of just doing a s/hlist_/list_/ replacement.

I'm fine with using list instead of hlist, but I don't understand why
you decided to open code list_for_each and list_for_each_safe instead
of using the macros provided by Xen. Is there an issue with such
macros?

I've made a couple of minor comments, but I think the current status
is good, and fixing those minor comments is going to be trivial.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] block: Remove blk_attach_dev_legacy() / legacy_dev code

2019-01-22 Thread Thomas Huth

On 2018-12-18 17:11, Thomas Huth wrote:
> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> is derived from XenDevice which in turn is derived from DeviceState
> since commit 3a6c9172ac5951e ("xen: create qdev for each backend device").
> Thus the code can also simply use blk_attach_dev() with a pointer
> to the DeviceState instead.
> So we can finally remove all code related to the "legacy_dev" flag, too,
> and turn the related "void *" in block-backend.c into "DeviceState *"
> to fix some of the remaining TODOs there.
> 
> Signed-off-by: Thomas Huth 
> ---
>  Note: I haven't tested the Xen code since I don't have a working Xen
>  installation at hand. I'd appreciate if someone could check it...

Ping?

>  block/block-backend.c  | 54 
> +++---
>  hw/block/xen_disk.c|  6 +++--
>  include/sysemu/block-backend.h |  5 ++--
>  3 files changed, 15 insertions(+), 50 deletions(-)
> 
> diff --git a/block/block-backend.c b/block/block-backend.c
> index 60d37a0..3c3118f 100644
> --- a/block/block-backend.c
> +++ b/block/block-backend.c
> @@ -47,9 +47,7 @@ struct BlockBackend {
>  QTAILQ_ENTRY(BlockBackend) monitor_link; /* for monitor_block_backends */
>  BlockBackendPublic public;
>  
> -void *dev;  /* attached device model, if any */
> -bool legacy_dev;/* true if dev is not a DeviceState */
> -/* TODO change to DeviceState when all users are qdevified */
> +DeviceState *dev;   /* attached device model, if any */
>  const BlockDevOps *dev_ops;
>  void *dev_opaque;
>  
> @@ -836,7 +834,11 @@ void blk_get_perm(BlockBackend *blk, uint64_t *perm, 
> uint64_t *shared_perm)
>  *shared_perm = blk->shared_perm;
>  }
>  
> -static int blk_do_attach_dev(BlockBackend *blk, void *dev)
> +/*
> + * Attach device model @dev to @blk.
> + * Return 0 on success, -EBUSY when a device model is attached already.
> + */
> +int blk_attach_dev(BlockBackend *blk, DeviceState *dev)
>  {
>  if (blk->dev) {
>  return -EBUSY;
> @@ -851,40 +853,16 @@ static int blk_do_attach_dev(BlockBackend *blk, void 
> *dev)
>  
>  blk_ref(blk);
>  blk->dev = dev;
> -blk->legacy_dev = false;
>  blk_iostatus_reset(blk);
>  
>  return 0;
>  }
>  
>  /*
> - * Attach device model @dev to @blk.
> - * Return 0 on success, -EBUSY when a device model is attached already.
> - */
> -int blk_attach_dev(BlockBackend *blk, DeviceState *dev)
> -{
> -return blk_do_attach_dev(blk, dev);
> -}
> -
> -/*
> - * Attach device model @dev to @blk.
> - * @blk must not have a device model attached already.
> - * TODO qdevified devices don't use this, remove when devices are qdevified
> - */
> -void blk_attach_dev_legacy(BlockBackend *blk, void *dev)
> -{
> -if (blk_do_attach_dev(blk, dev) < 0) {
> -abort();
> -}
> -blk->legacy_dev = true;
> -}
> -
> -/*
>   * Detach device model @dev from @blk.
>   * @dev must be currently attached to @blk.
>   */
> -void blk_detach_dev(BlockBackend *blk, void *dev)
> -/* TODO change to DeviceState *dev when all users are qdevified */
> +void blk_detach_dev(BlockBackend *blk, DeviceState *dev)
>  {
>  assert(blk->dev == dev);
>  blk->dev = NULL;
> @@ -898,8 +876,7 @@ void blk_detach_dev(BlockBackend *blk, void *dev)
>  /*
>   * Return the device model attached to @blk if any, else null.
>   */
> -void *blk_get_attached_dev(BlockBackend *blk)
> -/* TODO change to return DeviceState * when all users are qdevified */
> +DeviceState *blk_get_attached_dev(BlockBackend *blk)
>  {
>  return blk->dev;
>  }
> @@ -908,10 +885,7 @@ void *blk_get_attached_dev(BlockBackend *blk)
>   * device attached to the BlockBackend. */
>  char *blk_get_attached_dev_id(BlockBackend *blk)
>  {
> -DeviceState *dev;
> -
> -assert(!blk->legacy_dev);
> -dev = blk->dev;
> +DeviceState *dev = blk->dev;
>  
>  if (!dev) {
>  return g_strdup("");
> @@ -949,11 +923,6 @@ BlockBackend *blk_by_dev(void *dev)
>  void blk_set_dev_ops(BlockBackend *blk, const BlockDevOps *ops,
>   void *opaque)
>  {
> -/* All drivers that use blk_set_dev_ops() are qdevified and we want to 
> keep
> - * it that way, so we can assume blk->dev, if present, is a DeviceState 
> if
> - * blk->dev_ops is set. Non-device users may use dev_ops without device. 
> */
> -assert(!blk->legacy_dev);
> -
>  blk->dev_ops = ops;
>  blk->dev_opaque = opaque;
>  
> @@ -979,8 +948,6 @@ void blk_dev_change_media_cb(BlockBackend *blk, bool 
> load, Error **errp)
>  bool tray_was_open, tray_is_open;
>  Error *local_err = NULL;
>  
> -assert(!blk->legacy_dev);
> -
>  tray_was_open = blk_dev_is_tray_open(blk);
>  blk->dev_ops->change_media_cb(blk->dev_opaque, load, &local_err);
>  if (local_err) {
> @@ -1779,9 +1746,6 @@ void blk_eject(

Re: [Xen-devel] [PATCH 0/2] Dangling fixes for ARM iommu

2019-01-22 Thread Julien Grall




On 1/22/19 1:48 PM, Andrii Anisov wrote:

Hello Julien,


Hi,


On 21.01.19 19:29, Julien Grall wrote:

(+ Juergen)
All patches candidate for Xen 4.12 should have the release manager 
CCed and explain the pros/cons to have those patches for this release. 
It is also useful if you add for-4.12 (or similar) in the [...] so we 
can prioritize it.


I've got the point. Thank you for adding Juergen.

Indeed code base evolved, for instance iommu_use_hap_pt has a slight 
different behavior now.


Actually you properly pointed the problem. I'm not sure how it happened, 
because I did test build and run for those patches yesterday. But now, 
progressing with our stuff porting, I realized that the patch 1 is 
missing dependency on `xen/sched.h` required by `iommu_use_hap_pt`.



So please stripped my RB

OK.


The AB is arguable as it is quite old.

I could drop it for v2.


Yes please. But see below.



Secondly, it often happens that some patches have the required 
acked-by and reviewed-by but are not merged because they makes little 
sense without the rest of the series. 


Yes, sure, but fixes are still relevant and are quite autonomous. The 
only relation to the series is that they were discovered during its 
implementation.


A fix would be if you found a bug in a configuration that we are meant 
to support.




In that case, the current code base does not support the case where 
the P2M is not shared with the IOMMU and does not support new IOMMU 
bindings in the current setup.


It is the intention of the rest of the series.


The rest of series is not ready and not targeting 4.12. So why should we 
get them merged?




So I am not convinced they should be included in Xen 4.12 or even 
without the rest of the series.
IMO, the pure fixes, like patch 2, and the first hunk of patch 1 should 
be OK for 4.12.


The first hunk of patch 1 aside, we never supported the new IOMMU 
bindings nor unsharing the P2M. So what do you actually fix?


Supporting unshared P2M will require more work given because the code 
relies on mfn_to_gmfn that is not implemented on Arm. So accepting this 
patch standalone would be misleading as the rest of the series is not 
going to be merged in Xen 4.12.


Similarly, we don't support new IOMMU bindings. The patch #2 alone is 
going to add more trouble as now Dom0 would not be able to use the IOMMU 
if it were not hidden.


So I still question the usefulness of those 2 patches outside of the series.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 6/6] x86: xen: no need to check return value of debugfs_create functions

2019-01-22 Thread Greg Kroah-Hartman

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: 
Cc: 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/xen/debugfs.c | 7 +--
 arch/x86/xen/p2m.c | 3 ---
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
index 13da87918b4f..532410998684 100644
--- a/arch/x86/xen/debugfs.c
+++ b/arch/x86/xen/debugfs.c
@@ -9,13 +9,8 @@ static struct dentry *d_xen_debug;
 
 struct dentry * __init xen_init_debugfs(void)
 {
-   if (!d_xen_debug) {
+   if (!d_xen_debug)
d_xen_debug = debugfs_create_dir("xen", NULL);
-
-   if (!d_xen_debug)
-   pr_warning("Could not create 'xen' debugfs 
directory\n");
-   }
-
return d_xen_debug;
 }
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 055e37e43541..9d3e29805b73 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -810,9 +810,6 @@ static int __init xen_p2m_debugfs(void)
 {
struct dentry *d_xen = xen_init_debugfs();
 
-   if (d_xen == NULL)
-   return -ENOMEM;
-
d_mmu_debug = debugfs_create_dir("mmu", d_xen);
 
debugfs_create_file("p2m", 0600, d_mmu_debug, NULL, &p2m_dump_fops);
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] xen: fix xen-bus state model to allow frontend re-connection

There is a flaw in the xen-bus state model. To allow a frontend to re-
connect the backend state of an online XenDevice is transitioned from
Closed to InitWait, but this is currently done unilaterally which is
incorrect. The backend state should remain Closed until the frontend state
transitions to Initialising.

This patch removes the automatic backend state transition from
xen_device_backend_state_changed() and, instead, adds an extra check in
xen_device_frontend_state_changed() to determine whether a frontend is
trying to re-connect to a previously Closed XenDevice. Only if this is
found to be the case is the backend state transitioned from Closed to
InitWait. Note that this transition will be common amongst all XenDevice
classes and hence xen_device_frontend_state_changed() returns immediately
afterwards without calling into the XenDeviceClass frontend_changed()
method.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
---
 hw/xen/xen-bus.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 3aeccec69c..1b31a1dc50 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -547,20 +547,12 @@ static void xen_device_backend_changed(void *opaque)
 }
 
 /*
- * If a backend is still 'online' then its state should be cycled
- * back round to InitWait in order for a new frontend instance to
- * connect. This may happen when, for example, a frontend driver is
- * re-installed or updated.
- * If a backend is not 'online' then the device should be destroyed.
+ * If a backend is still 'online' then we should leave it alone but,
+ * if a backend is not 'online', then the device should be destroyed
+ * once the state is Closed.
  */
-if (xendev->backend_online &&
+if (!xendev->backend_online &&
 xendev->backend_state == XenbusStateClosed) {
-xen_device_backend_set_state(xendev, XenbusStateInitWait);
-} else if (!xendev->backend_online &&
-   (xendev->backend_state == XenbusStateClosed ||
-xendev->backend_state == XenbusStateInitialising ||
-xendev->backend_state == XenbusStateInitWait ||
-xendev->backend_state == XenbusStateUnknown)) {
 Error *local_err = NULL;
 
 if (!xen_backend_try_device_destroy(xendev, &local_err)) {
@@ -715,6 +707,17 @@ static void xen_device_frontend_changed(void *opaque)
 
 xen_device_frontend_set_state(xendev, state);
 
+if (state == XenbusStateInitialising &&
+xendev->backend_state == XenbusStateClosed &&
+xendev->backend_online) {
+/*
+ * The frontend is re-initializing so switch back to
+ * InitWait.
+ */
+xen_device_backend_set_state(xendev, XenbusStateInitWait);
+return;
+}
+
 if (xendev_class->frontend_changed) {
 Error *local_err = NULL;
 
-- 
2.20.1.2.gb21ebb6


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] block: Remove blk_attach_dev_legacy() / legacy_dev code

2019-01-22 Thread Kevin Wolf

Am 22.01.2019 um 15:19 hat Thomas Huth geschrieben:
> On 2018-12-18 17:11, Thomas Huth wrote:
> > The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> > It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> > is derived from XenDevice which in turn is derived from DeviceState
> > since commit 3a6c9172ac5951e ("xen: create qdev for each backend device").
> > Thus the code can also simply use blk_attach_dev() with a pointer
> > to the DeviceState instead.
> > So we can finally remove all code related to the "legacy_dev" flag, too,
> > and turn the related "void *" in block-backend.c into "DeviceState *"
> > to fix some of the remaining TODOs there.
> > 
> > Signed-off-by: Thomas Huth 
> > ---
> >  Note: I haven't tested the Xen code since I don't have a working Xen
> >  installation at hand. I'd appreciate if someone could check it...
> 
> Ping?

This needs a rebase. xen_disk.c doesn't even exist any more and
blk_attach_dev_legacy() is really dead code now.

The work on the Xen block device is the reason why I didn't merge this
patch yet. I thought I had sent a reply to that effect, but it seems I
hadn't. Sorry for that!

Kevin

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] block: Remove blk_attach_dev_legacy() / legacy_dev code

2019-01-22 Thread Thomas Huth

On 2019-01-22 15:46, Kevin Wolf wrote:
> Am 22.01.2019 um 15:19 hat Thomas Huth geschrieben:
>> On 2018-12-18 17:11, Thomas Huth wrote:
>>> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
>>> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
>>> is derived from XenDevice which in turn is derived from DeviceState
>>> since commit 3a6c9172ac5951e ("xen: create qdev for each backend device").
>>> Thus the code can also simply use blk_attach_dev() with a pointer
>>> to the DeviceState instead.
>>> So we can finally remove all code related to the "legacy_dev" flag, too,
>>> and turn the related "void *" in block-backend.c into "DeviceState *"
>>> to fix some of the remaining TODOs there.
>>>
>>> Signed-off-by: Thomas Huth 
>>> ---
>>>  Note: I haven't tested the Xen code since I don't have a working Xen
>>>  installation at hand. I'd appreciate if someone could check it...
>>
>> Ping?
> 
> This needs a rebase. xen_disk.c doesn't even exist any more and
> blk_attach_dev_legacy() is really dead code now.

Ah, great, that makes it even easier! I'll send a v2 to remove the
remainders...

 Thomas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 132342: tolerable all pass - PUSHED

flight 132342 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132342/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  08b908ba63dee8bc313983c5e412852cbcbcda85
baseline version:
 xen  53a84f672df7eb183c857f028dfa80974bf61dd6

Last test of basis   132287  2019-01-21 19:00:39 Z0 days
Testing same since   132342  2019-01-22 12:00:34 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   53a84f672d..08b908ba63  08b908ba63dee8bc313983c5e412852cbcbcda85 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable test] 132230: tolerable FAIL

flight 132230 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132230/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132093
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 132093
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 132093
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 132093
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 132093
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 132093
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 132093
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 132093
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 132093
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  1912f1220cf87aee28349469893f101980714a05
baseline version:
 xen  1912f1220cf87aee28349469893f101980714a05

Last test of basis   132230  2019-01-21 02:07:39 Z1 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1

Re: [Xen-devel] [PATCH] xen: fix xen-bus state model to allow frontend re-connection

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 22 January 2019 14:40
> To: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony Perard 
> Subject: [PATCH] xen: fix xen-bus state model to allow frontend re-
> connection
> 
> There is a flaw in the xen-bus state model. To allow a frontend to re-
> connect the backend state of an online XenDevice is transitioned from
> Closed to InitWait, but this is currently done unilaterally which is
> incorrect. The backend state should remain Closed until the frontend state
> transitions to Initialising.
> 
> This patch removes the automatic backend state transition from
> xen_device_backend_state_changed() and, instead, adds an extra check in
> xen_device_frontend_state_changed() to determine whether a frontend is
> trying to re-connect to a previously Closed XenDevice. Only if this is
> found to be the case is the backend state transitioned from Closed to
> InitWait. Note that this transition will be common amongst all XenDevice
> classes and hence xen_device_frontend_state_changed() returns immediately
> afterwards without calling into the XenDeviceClass frontend_changed()
> method.
> 
> Signed-off-by: Paul Durrant 

Unfortunately this is still not quite right. Further testing has now shown that 
xl block-detach is no longer working properly. I'll send a v2 once that is 
fixed.

  Paul

> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> ---
>  hw/xen/xen-bus.c | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
> index 3aeccec69c..1b31a1dc50 100644
> --- a/hw/xen/xen-bus.c
> +++ b/hw/xen/xen-bus.c
> @@ -547,20 +547,12 @@ static void xen_device_backend_changed(void *opaque)
>  }
> 
>  /*
> - * If a backend is still 'online' then its state should be cycled
> - * back round to InitWait in order for a new frontend instance to
> - * connect. This may happen when, for example, a frontend driver is
> - * re-installed or updated.
> - * If a backend is not 'online' then the device should be destroyed.
> + * If a backend is still 'online' then we should leave it alone but,
> + * if a backend is not 'online', then the device should be destroyed
> + * once the state is Closed.
>   */
> -if (xendev->backend_online &&
> +if (!xendev->backend_online &&
>  xendev->backend_state == XenbusStateClosed) {
> -xen_device_backend_set_state(xendev, XenbusStateInitWait);
> -} else if (!xendev->backend_online &&
> -   (xendev->backend_state == XenbusStateClosed ||
> -xendev->backend_state == XenbusStateInitialising ||
> -xendev->backend_state == XenbusStateInitWait ||
> -xendev->backend_state == XenbusStateUnknown)) {
>  Error *local_err = NULL;
> 
>  if (!xen_backend_try_device_destroy(xendev, &local_err)) {
> @@ -715,6 +707,17 @@ static void xen_device_frontend_changed(void *opaque)
> 
>  xen_device_frontend_set_state(xendev, state);
> 
> +if (state == XenbusStateInitialising &&
> +xendev->backend_state == XenbusStateClosed &&
> +xendev->backend_online) {
> +/*
> + * The frontend is re-initializing so switch back to
> + * InitWait.
> + */
> +xen_device_backend_set_state(xendev, XenbusStateInitWait);
> +return;
> +}
> +
>  if (xendev_class->frontend_changed) {
>  Error *local_err = NULL;
> 
> --
> 2.20.1.2.gb21ebb6


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2] xen: fix xen-bus state model to allow frontend re-connection

There is a flaw in the xen-bus state model. To allow a frontend to re-
connect the backend state of an online XenDevice is transitioned from
Closed to InitWait, but this is currently done unilaterally which is
incorrect. The backend state should remain Closed until the frontend state
transitions to Initialising.

This patch removes the automatic backend state transition from
xen_device_backend_state_changed() and, instead, adds an extra check in
xen_device_frontend_state_changed() to determine whether a frontend is
trying to re-connect to a previously Closed XenDevice. Only if this is
found to be the case is the backend state transitioned from Closed to
InitWait. Note that this transition will be common amongst all XenDevice
classes and hence xen_device_frontend_state_changed() returns immediately
afterwards without calling into the XenDeviceClass frontend_changed()
method.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

v2:
 - Fix xl block-detach
---
 hw/xen/xen-bus.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 3aeccec69c..49a725e8c7 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -547,20 +547,15 @@ static void xen_device_backend_changed(void *opaque)
 }
 
 /*
- * If a backend is still 'online' then its state should be cycled
- * back round to InitWait in order for a new frontend instance to
- * connect. This may happen when, for example, a frontend driver is
- * re-installed or updated.
- * If a backend is not 'online' then the device should be destroyed.
+ * If a backend is still 'online' then we should leave it alone but,
+ * if a backend is not 'online', then the device should be destroyed
+ * once the state is Closed.
  */
-if (xendev->backend_online &&
-xendev->backend_state == XenbusStateClosed) {
-xen_device_backend_set_state(xendev, XenbusStateInitWait);
-} else if (!xendev->backend_online &&
-   (xendev->backend_state == XenbusStateClosed ||
-xendev->backend_state == XenbusStateInitialising ||
-xendev->backend_state == XenbusStateInitWait ||
-xendev->backend_state == XenbusStateUnknown)) {
+if (!xendev->backend_online &&
+(xendev->backend_state == XenbusStateClosed ||
+ xendev->backend_state == XenbusStateInitialising ||
+ xendev->backend_state == XenbusStateInitWait ||
+ xendev->backend_state == XenbusStateUnknown)) {
 Error *local_err = NULL;
 
 if (!xen_backend_try_device_destroy(xendev, &local_err)) {
@@ -715,6 +710,17 @@ static void xen_device_frontend_changed(void *opaque)
 
 xen_device_frontend_set_state(xendev, state);
 
+if (state == XenbusStateInitialising &&
+xendev->backend_state == XenbusStateClosed &&
+xendev->backend_online) {
+/*
+ * The frontend is re-initializing so switch back to
+ * InitWait.
+ */
+xen_device_backend_set_state(xendev, XenbusStateInitWait);
+return;
+}
+
 if (xendev_class->frontend_changed) {
 Error *local_err = NULL;
 
-- 
2.20.1.2.gb21ebb6


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [tip:x86/urgent] x86/entry/64/compat: Fix stack switching for XEN PV

2019-01-22 Thread Sasha Levin

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 7f2590a110b8 x86/entry/64: Use a per-CPU trampoline stack for 
IDT entries.

The bot has tested the following trees: v4.20.3, v4.19.16, v4.14.94.

v4.20.3: Build OK!
v4.19.16: Build OK!
v4.14.94: Failed to apply! Possible dependencies:
0e34d226342c ("x86/entry/64: Move PUSH_AND_CLEAR_REGS from interrupt macro 
to helper function")
2ba6474104a1 ("x86/entry/64: Move ENTER_IRQ_STACK from interrupt macro to 
interrupt_entry")
90a6acc4e7eb ("x86/entry/64: Move the switch_to_thread_stack() call to 
interrupt_entry()")
91c5f0de64a2 ("x86/entry/64/compat: Save one instruction in 
entry_INT80_compat()")
b2855d8d2de0 ("x86/entry/64: Move ASM_CLAC to interrupt_entry()")
f3d415ea4696 ("x86/entry/64: Open-code switch_to_thread_stack()")


How should we proceed with this patch?

--
Thanks,
Sasha

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

2019-01-22 Thread Chao Gao

On Tue, Jan 22, 2019 at 01:24:48AM -0700, Jan Beulich wrote:
 On 22.01.19 at 06:50,  wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>>>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
 @@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg, u8 
 bus, u8 devfn)
  if ( !pdev )
  return -ENODEV;
  
 +pci_unmap_msi(pdev);
>>>
>>>Just want to make sure, since deassign_device will be called for both
>>>PV and HVM domains. AFAICT pci_unmap_msi is safe to call when the
>>>device is assigned to a PV guest, but would like your confirmation.
>> 
>> Tested with a PV guest loaded by Pygrub. PV guest doesn't suffer the
>> msi-x issue I want to fix.
>> 
>> With these three patches applied, I got some error messages from Xen
>> and Dom0 as follow:
>> 
>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 332
>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 331
>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 328
>> (XEN) irq.c:2148: dom3: pirq 359 not mapped
>> [ 2887.067685] xen:events: unmap irq failed -22
>> (XEN) irq.c:2148: dom3: pirq 358 not mapped
>> [ 2887.075917] xen:events: unmap irq failed -22
>> (XEN) irq.c:2148: dom3: pirq 357 not mapped
>> 
>> It seems, the cause of such error is that pirq-s are unmapped and forcibly
>> unbound on deassignment; subsequent unmapping pirq issued by dom0 fail.
>> From some aspects, this error is expected. Because with this patch,
>> pirq-s are expected to be mapped by qemu or dom0 kernel (for pv case) before
>> deassignment and mapping/binding pirq after deassignment should fail.
>> 
>> So what's your opinion on handling such error? We should figure out another
>> method to fix msi-x issue to avoid such error or suppress these errors in
>> qemu and linux kernel?
>
>The "forcing unbind" ones are probably fine to leave alone, but
>the errors would better be avoided in Xen (i.e. without a need
>to also change qemu and/or Linux). Since you don't really say
>when / why these errors now surface, it's hard to suggest what
>might be best to do.

With these patches applied, these errors surface in three cases:
1. destroy the PV guest with assigned devices by "xl destroy"
2. hot-unplug a assigned device from the PV guest
3. shut down the PV guest by executing "init 0" in guest (only for some
devices whose driver doesn't clean up MSI-x when shutdown)

The reason is:
when detaching a device from a domain, Toolstack always calls
xc_deassign_device() prior to libxl__device_pci_remove_xenstore().
The latter notifies xen_pciback to clean up the pci devices. I guess
unbinding and unmapping pirq are steps of the cleanup (just like
qemu's role in device deassignment for HVM guest). But in this patch,
pirqs are forcibly unmapped when calling xc_deassign_device(). Thus when
xen_pciback tries to unmap pirqs as usual, xen reports this pirq isn't
mapped and propagates this error to xen_pciback.

Thanks
Chao

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

2019-01-22 Thread Chao Gao

On Tue, Jan 22, 2019 at 10:18:55AM +0100, Roger Pau Monné wrote:
>On Tue, Jan 22, 2019 at 01:50:20PM +0800, Chao Gao wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>> >> +}
>> >> +}
>> >> +/*
>> >> + * All pirq-s should have been unmapped and corresponding msi_desc
>> >> + * entries should have been removed in the above loop.
>> >> + */
>> >> +ASSERT(list_empty(&pdev->msi_list));
>> >> +
>> >> +spin_unlock(&d->event_lock);
>> >> +}
>> >> +
>> >>  /* caller should hold the pcidevs_lock */
>> >>  int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
>> >>  {
>> >> @@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg, u8 
>> >> bus, u8 devfn)
>> >>  if ( !pdev )
>> >>  return -ENODEV;
>> >>  
>> >> +pci_unmap_msi(pdev);
>> >
>> >Just want to make sure, since deassign_device will be called for both
>> >PV and HVM domains. AFAICT pci_unmap_msi is safe to call when the
>> >device is assigned to a PV guest, but would like your confirmation.
>> 
>> Tested with a PV guest loaded by Pygrub. PV guest doesn't suffer the
>> msi-x issue I want to fix.
>> 
>> With these three patches applied, I got some error messages from Xen
>> and Dom0 as follow:
>> 
>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 332
>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 331
>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 328
>> (XEN) irq.c:2148: dom3: pirq 359 not mapped
>> [ 2887.067685] xen:events: unmap irq failed -22
>> (XEN) irq.c:2148: dom3: pirq 358 not mapped
>> [ 2887.075917] xen:events: unmap irq failed -22
>> (XEN) irq.c:2148: dom3: pirq 357 not mapped
>> 
>> It seems, the cause of such error is that pirq-s are unmapped and forcibly
>> unbound on deassignment; subsequent unmapping pirq issued by dom0 fail.
>> From some aspects, this error is expected. Because with this patch,
>> pirq-s are expected to be mapped by qemu or dom0 kernel (for pv case) before
>> deassignment and mapping/binding pirq after deassignment should fail.
>
>This is quite entangled because it involves Xen, libxl and pciback.
>
>AFAICT libxl will already try to unmap the pirqs before deassigning
>the device if the domain is PV, see do_pci_remove in libxl_pci.c and
>the calls it makes to xc_physdev_unmap_pirq.

It seems it only unmaps the pirq bound to INTx.

>
>Which makes me wonder, have you tested if you see those messages about
>pirq unmap failure without this patch applied?

No such error without my patch.

>
>> So what's your opinion on handling such error? We should figure out another
>> method to fix msi-x issue to avoid such error or suppress these errors in
>> qemu and linux kernel?
>
>Regardless of the reply to the question above, I think
>unmap_domain_pirq should return ESRCH if the pirq cannot be found,
>like the patch below. That would turn the Linux kernel messages into
>less scary info messages, like:
>
>"domain %d does not have %d anymore"
>
>Which seems more accurate.

I agree with you.

Thanks
Chao


>Thanks, Roger.
>
>---8<---
>diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
>index 23b4f423e6..7e9c974ba1 100644
>--- a/xen/arch/x86/irq.c
>+++ b/xen/arch/x86/irq.c
>@@ -2144,9 +2144,9 @@ int unmap_domain_pirq(struct domain *d, int pirq)
> info = pirq_info(d, pirq);
> if ( !info || (irq = info->arch.irq) <= 0 )
> {
>-dprintk(XENLOG_G_ERR, "dom%d: pirq %d not mapped\n",
>+dprintk(XENLOG_G_INFO, "dom%d: pirq %d not mapped\n",
> d->domain_id, pirq);
>-ret = -EINVAL;
>+ret = -ESRCH;
> goto done;
> }
> 
>

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 132302: regressions - FAIL

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

Regressions :-(

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

version targeted for testing:
 ovmf 8f470eb4768f69b675295080db0962ba503a743d
baseline version:
 ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188

Last test of basis   129475  2018-11-05 21:13:11 Z   77 days
Failing since129526  2018-11-06 20:49:26 Z   76 days  272 attempts
Testing same since   132302  2019-01-21 23:11:06 Z0 days1 attempts


People who touched revisions under test:
  Achin Gupta 
  Alex James 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  bob.c.f...@intel.com 
  BobCF 
  Carsey, Jaben 
  Chasel Chiu 
  Chasel, Chiu 
  Chen A Chen 
  Chu, Maggie 
  Dandan Bi 
  David Wei 
  Derek Lin 
  Eric Dong 
  Eugene Cohen 
  Fan, ZhijuX 
  Felix Polyudov 
  Feng, Bob C 
  Fu Siyuan 
  Gary Lin 
  Hao Wu 
  Jaben Carsey 
  Jagadeesh Ujja 
  Jeff Brasen 
  Jian J Wang 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Liu Yu 
  Maggie Chu 
  Marc Zyngier 
  Marcin Wojtas 
  Mike Maslenkin 
  Ming Huang 
  Pedroa Liu 
  Ray Ni 
  Ruiyu Ni 
  Sami Mujawar 
  shenglei 
  Shenglei Zhang 
  Siyuan Fu 
  Songpeng Li 
  Star Zeng 
  Sughosh Ganu 
  Sumit Garg 
  Sun, Zailiang 
  Thomas Abraham 
  Thomas Rydman 
  Ting Ye 
  Tomasz Michalec 
  Vijayenthiran Subramaniam 
  Vladimir Olovyannikov 
  Wang BinX A 
  Wu Jiaxin 
  Ye Ting 
  Yonghong Zhu 
  yuchenlin 
  Zailiang Sun 
  Zhang, Chao B 
  Zhao, ZhiqiangX 
  Zhiju.Fan 
  zhijufan 
  ZhiqiangX Zhao 
  zwei4 

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



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

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

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

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


Not pushing.

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

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen-unstable PVHdom0: Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at iommu.c:324

On Sun, Jan 20, 2019 at 11:09:25PM +0100, Sander Eikelenboom wrote:
> On 18/01/2019 18:56, Roger Pau Monné wrote:
> > On Fri, Jan 18, 2019 at 03:17:57PM +0100, Sander Eikelenboom wrote:
> >> On 18/01/2019 13:50, Roger Pau Monné wrote:
> >>> On Fri, Jan 18, 2019 at 01:03:04PM +0100, Sander Eikelenboom wrote:
>  Hi Roger,
> 
>  I gave PVH dom0 a spin, see how far I would get.
> >>>
> >>> Thanks!
> >>>
>  With current xen-unstable unfortunately not that far, i got the splat 
>  below.
> >>>
> >>> Yes, this was already reported:
> >>>
> >>> https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01030.html
>  If you need more info, would like me to test a patch (or some other git 
>  tree/branch), 
>  I will be happy to give it a spin !
> >>>
> >>> Paul is working on a fix, but in the meantime just removing the
> >>> assertions should be fine:
> >>>
> >>> ---8<---
> >>> diff --git a/xen/drivers/passthrough/iommu.c 
> >>> b/xen/drivers/passthrough/iommu.c
> >>> index bd1af35a13..98e6fc35e2 100644
> >>> --- a/xen/drivers/passthrough/iommu.c
> >>> +++ b/xen/drivers/passthrough/iommu.c
> >>> @@ -321,9 +321,6 @@ int iommu_map(struct domain *d, dfn_t dfn, mfn_t mfn,
> >>>  if ( !iommu_enabled || !hd->platform_ops )
> >>>  return 0;
> >>>  
> >>> -ASSERT(IS_ALIGNED(dfn_x(dfn), (1ul << page_order)));
> >>> -ASSERT(IS_ALIGNED(mfn_x(mfn), (1ul << page_order)));
> >>> -
> >>>  for ( i = 0; i < (1ul << page_order); i++ )
> >>>  {
> >>>  rc = hd->platform_ops->map_page(d, dfn_add(dfn, i), mfn_add(mfn, 
> >>> i),
> >>>
> >>
> >> I gave that a spin and i now get a seemingly endless stream of 
> >> IO_PAGE_FAULTs
> > 
> > You shouldn't get those page faults since they are for addresses that
> > belong to a reserved region, and that should be mapped into the p2m.
> > I've just tested on my AMD box and I'm also seeing errors (albeit
> > different ones), so I guess something broke since I last fixed PVH
> > Dom0 to boot on AMD hardware.
> > 
> > I've also tested commit:
> > 
> > commit fad6ba64a8c98bebb9374f390cc255fac05237ab (HEAD)
> > Author: Roger Pau Monné 
> > Date:   Fri Nov 30 12:10:00 2018 +0100
> > amd/iommu: skip host bridge devices when updating IOMMU page tables
> > 
> > And it works on my AMD box and I'm able to boot as a PVH Dom0. Can you
> > give this commit a spin?
> > 
> > Thanks, Roger.
> > 
> 
> Hi Roger,
> 
> Tested that commit, but that didn't help.

Thanks! Sorry for the delay, I got sidetracked with something else.

Can you please post the serial log when using the above commit?

> I added some debug logging (to xen-unstable + Paul's patch) and found out the 
> devices that are giving
> the IO_PAGE_FAULTs are the onboard USB controllers (0x90 0x92 0x98 0xa5).
>
> If I skip calling "amd_iommu_setup_domain_device" for these devices I can at 
> least get it to boot a linux kernel 
> (which than gives problems with the SATA controller, but that would be a next 
> step). The patch I used is below.
> 
> I attached the output from lspci -vvvknn, perhaps you can spot something odd ?
> When booting dom0 as PV instead of PVH everything boots and works fine.

There's definitely something wrong in Xen, so workarounds won't get
you very far. This needs to be properly fixed in the hypervisor.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

>>> On 22.01.19 at 17:08,  wrote:
> On Tue, Jan 22, 2019 at 01:24:48AM -0700, Jan Beulich wrote:
> On 22.01.19 at 06:50,  wrote:
>>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> @@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg, u8 
> bus, 
> u8 devfn)
>  if ( !pdev )
>  return -ENODEV;
>  
> +pci_unmap_msi(pdev);

Just want to make sure, since deassign_device will be called for both
PV and HVM domains. AFAICT pci_unmap_msi is safe to call when the
device is assigned to a PV guest, but would like your confirmation.
>>> 
>>> Tested with a PV guest loaded by Pygrub. PV guest doesn't suffer the
>>> msi-x issue I want to fix.
>>> 
>>> With these three patches applied, I got some error messages from Xen
>>> and Dom0 as follow:
>>> 
>>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 332
>>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 331
>>> (XEN) irq.c:2176: dom3: forcing unbind of pirq 328
>>> (XEN) irq.c:2148: dom3: pirq 359 not mapped
>>> [ 2887.067685] xen:events: unmap irq failed -22
>>> (XEN) irq.c:2148: dom3: pirq 358 not mapped
>>> [ 2887.075917] xen:events: unmap irq failed -22
>>> (XEN) irq.c:2148: dom3: pirq 357 not mapped
>>> 
>>> It seems, the cause of such error is that pirq-s are unmapped and forcibly
>>> unbound on deassignment; subsequent unmapping pirq issued by dom0 fail.
>>> From some aspects, this error is expected. Because with this patch,
>>> pirq-s are expected to be mapped by qemu or dom0 kernel (for pv case) before
>>> deassignment and mapping/binding pirq after deassignment should fail.
>>> 
>>> So what's your opinion on handling such error? We should figure out another
>>> method to fix msi-x issue to avoid such error or suppress these errors in
>>> qemu and linux kernel?
>>
>>The "forcing unbind" ones are probably fine to leave alone, but
>>the errors would better be avoided in Xen (i.e. without a need
>>to also change qemu and/or Linux). Since you don't really say
>>when / why these errors now surface, it's hard to suggest what
>>might be best to do.
> 
> With these patches applied, these errors surface in three cases:
> 1. destroy the PV guest with assigned devices by "xl destroy"
> 2. hot-unplug a assigned device from the PV guest
> 3. shut down the PV guest by executing "init 0" in guest (only for some
> devices whose driver doesn't clean up MSI-x when shutdown)
> 
> The reason is:
> when detaching a device from a domain, Toolstack always calls
> xc_deassign_device() prior to libxl__device_pci_remove_xenstore().
> The latter notifies xen_pciback to clean up the pci devices. I guess
> unbinding and unmapping pirq are steps of the cleanup (just like
> qemu's role in device deassignment for HVM guest). But in this patch,
> pirqs are forcibly unmapped when calling xc_deassign_device(). Thus when
> xen_pciback tries to unmap pirqs as usual, xen reports this pirq isn't
> mapped and propagates this error to xen_pciback.

Why are you talking about pciback here? I don't think it plays any
role in IRQ unmapping. If what the tool stack does if going to be
fully taen care of by the hypervisor, I think that tool stack code
could the be deleted (unless compatibility requirements don't
allow doing so, in which case it could be conditionally bypassed).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] iommu: specify page_count rather than page_order to iommu_map/unmap()...

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 22 January 2019 10:47
> To: Paul Durrant 
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ; Roger Pau Monne ;
> Wei Liu ; Sander Eikelenboom ;
> Chao Gao ; Jun Nakajima ;
> Kevin Tian ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
> 
> Subject: RE: [PATCH] iommu: specify page_count rather than page_order to
> iommu_map/unmap()...
> 
> >>> On 21.01.19 at 14:22,  wrote:
> >>  -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 21 January 2019 12:05
> >> To: Paul Durrant 
> >> Cc: Julien Grall ; Andrew Cooper
> >> ; George Dunlap ;
> Ian
> >> Jackson ; Roger Pau Monne
> ;
> >> Wei Liu ; Sander Eikelenboom
> ;
> >> Chao Gao ; Jun Nakajima ;
> >> Kevin Tian ; Stefano Stabellini
> >> ; xen-devel ;
> >> Konrad Rzeszutek Wilk ; Tim (Xen.org)
> >> 
> >> Subject: RE: [PATCH] iommu: specify page_count rather than page_order
> to
> >> iommu_map/unmap()...
> >>
> >> >>> On 21.01.19 at 12:56,  wrote:
> >> >>  -Original Message-
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: 21 January 2019 11:28
> >> >> To: Paul Durrant 
> >> >> Cc: Julien Grall ; Andrew Cooper
> >> >> ; Roger Pau Monne ;
> >> Wei
> >> >> Liu ; Sander Eikelenboom
> ;
> >> >> George Dunlap ; Ian Jackson
> >> >> ; Chao Gao ; Jun
> Nakajima
> >> >> ; Kevin Tian ; Stefano
> >> >> Stabellini ; xen-devel  >> >> de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> >> >> ; Tim (Xen.org) 
> >> >> Subject: Re: [PATCH] iommu: specify page_count rather than
> page_order
> >> to
> >> >> iommu_map/unmap()...
> >> >>
> >> >> >>> On 18.01.19 at 17:03,  wrote:
> >> >> > ...and remove alignment assertions.
> >> >> >
> >> >> > Testing shows that certain callers of iommu_legacy_map/unmap()
> >> specify
> >> >> > order > 0 ranges that are not order aligned thus causing one of
> the
> >> >> > IS_ALIGNED() assertions to fire.
> >> >>
> >> >> As said before - without a much better explanation of why the
> current
> >> >> order-based model is unsuitable (so far I've been provided only
> vague
> >> >> pointers into "somewhere in PVH Dom0 boot code" iirc) to understand
> >> >> why it's undesirable to simply make those call sites obey to the
> >> current
> >> >> requirements, I'm not happy to see us go this route.
> >> >
> >> > I thought...
> >> >
> >> > "Using a count actually makes more sense because the valid
> >> > set of mapping orders is specific to the IOMMU implementation and to
> it
> >> > should be up to the implementation specific code to translate a
> mapping
> >> > count into an optimal set of mapping orders (when the code is finally
> >> > modified to support orders > 0)."
> >> >
> >> > ...was reasonably clear. Is that not a reasonable justification? What
> >> else
> >> > could I say?
> >>
> >> Well, I was hoping to be pointed at the (apparently multiple) call
> sites
> >> where making them match the current function pattern is more involved
> >> and/or less desirable than changing the functions here.
> >
> > AFAICT, one of them is memory.c:populate_physmap() where the extent
> order
> > comes from the memop_args and the memory comes from
> alloc_domheap_pages(),
> > which I don't believe aligns memory on the specified order.
> 
> Of course it does (in MFN space). What I notice is that the gpfn passed
> in is not validated to be suitably aligned for the specified order. With
> guest_physmap_add_entry() processing each 4k page separately this
> doesn't currently have any bad effects, but I think it's a bug
> nevertheless. After all the comment in struct xen_memory_reservation's
> declaration says "size/alignment of each". The issue with fixing flaws
> like this is that there's always the risk of causing regressions with
> existing guests.
> 
> > Regardless of the
> > alignment though, the fact that order comes from a hypercall argument
> and may
> > not match any of the orders supported by the IOMMU implementation makes
> me
> > think that using a page count is better.
> 
> Splitting up guest requests is orthogonal to whether a count or an
> order is more suitable as a parameter.

Ok, I'm not prepared to argue the point any more. I withdraw the patch.

  Paul

> 
> Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] iommu: specify page_count rather than page_order to iommu_map/unmap()...

On Mon, Jan 21, 2019 at 04:27:38AM -0700, Jan Beulich wrote:
> >>> On 18.01.19 at 17:03,  wrote:
> > ...and remove alignment assertions.
> > 
> > Testing shows that certain callers of iommu_legacy_map/unmap() specify
> > order > 0 ranges that are not order aligned thus causing one of the
> > IS_ALIGNED() assertions to fire.
> 
> As said before - without a much better explanation of why the current
> order-based model is unsuitable (so far I've been provided only vague
> pointers into "somewhere in PVH Dom0 boot code" iirc) to understand
> why it's undesirable to simply make those call sites obey to the current
> requirements, I'm not happy to see us go this route.

The current PVH dom0 builder will try to always use the biggest
possible order to populate the physmap.

However, the memory map used by dom0 is not under our control, so it's
quite likely that a RAM region starts at a 4K only aligned address.
dom0 builder will then find the next 2M or 1G aligned address and
populate the space between the current address and the next aligned
address using an order as high as possible. In the above scenario,
it's perfectly fine to populate a 4K aligned entry using an order of 5
for example, in order to reach the next 2M or 1G aligned address.

Not removing the asserts would imply that in the above example the
dom0 builder has to iterate over all the 4K pages and make repeated
guest_physmap_add_page calls with order 0. This is sub-optimal,
creates a non-trivial overhead to the Dom0 builder, and also promotes
the open-coding of loops around guest_physmap_add_page.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] arm64/xen: fix xen-swiotlb cache flushing

2019-01-22 Thread Christoph Hellwig

On Mon, Jan 21, 2019 at 03:56:29PM -0800, Stefano Stabellini wrote:
> > Where should we pick this up?  I could pick it up through the dma-mapping
> > tree given that is where the problem is introduced, but the Xen or arm64
> > trees would also fit.
> 
> I am happy for you to carry it in the dma-mapping tree, especially if
> you have other fixes to send. Otherwise, let me know.

Thanks, I've queued it up for Linus.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [libvirt test] 132318: tolerable all pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 132083
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 132083
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  fb0d0d6c5492a427bc4d1813257f6ad77bb0ea70
baseline version:
 libvirt  40136bd3168a09c2524440d3b734015f0b618a05

Last test of basis   132083  2019-01-19 07:02:13 Z3 days
Testing same since   132318  2019-01-22 04:18:53 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Daniel P. Berrangé 
  Ján Tomko 
  Mark McLoughlin 
  Peter Krempa 
  Radostin Stoyanov 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   40136bd316..fb0d0d6c54  fb0d0d6c5492a427bc4d1813257f6ad77bb0ea70 -> 
xen-tested-master

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] iommu: specify page_count rather than page_order to iommu_map/unmap()...

2019-01-22 Thread Andrew Cooper

On 22/01/2019 10:46, Jan Beulich wrote:
>
>> Regardless of the 
>> alignment though, the fact that order comes from a hypercall argument and 
>> may 
>> not match any of the orders supported by the IOMMU implementation makes me 
>> think that using a page count is better.
> Splitting up guest requests is orthogonal to whether a count or an
> order is more suitable as a parameter.

No - this is most certainly not true.

Any arbitrary mapping can be expressed with a single map call, given a
start/count.  This is not true of a start/order pair, so start/count is
strictly more expressive.

Furthermore, I've already given the following concrete options as to why
start/count is better than start/order:  Reduced caller looping, reduced
TLB flushing in the current implementation, and the fact we literally
have hypercalls using this mechanism who's API is stable.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [seabios test] 132271: tolerable FAIL - PUSHED

flight 132271 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132271/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131437
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 131437
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131437
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 131437
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  d62ca8c9c53f375b69a85da0aafe5aaced79642f
baseline version:
 seabios  29ba89e67ff39b7673912022bf54c8640ae113cd

Last test of basis   131437  2018-12-19 00:11:08 Z   34 days
Testing same since   132199  2019-01-20 17:10:53 Z2 days2 attempts


People who touched revisions under test:
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictpass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/seabios.git
   29ba89e..d62ca8c  d62ca8c9c53f375b69a85da0aafe5aaced79642f -> 
xen-tested-master

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain

2019-01-22 Thread Stefano Stabellini

On Mon, 21 Jan 2019, Peng Fan wrote:
> on i.MX8QM, M4_1 is communicating with DomU using rpmsg with a fixed
> address as the dma mem buffer which is predefined.
> 
> Without this patch, the flow is:
> vring_map_one_sg -> vring_use_dma_api
>  -> dma_map_page
>  -> __swiotlb_map_page
>   ->swiotlb_map_page
>   ->__dma_map_area(phys_to_virt(dma_to_phys(dev, 
> dev_addr)), size, dir);
> However we are using per device dma area for rpmsg, phys_to_virt
> could not return a correct virtual address for virtual address in
> vmalloc area. Then kernel panic.
> 
> With this patch, vring_use_dma_api will return false, and
> vring_map_one_sg will return sg_phys(sg) which is the correct phys
> address in the predefined memory region.
> vring_map_one_sg -> vring_use_dma_api
>  -> sg_phys(sg)
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/virtio/virtio_ring.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index cd7e755484e3..8993d7cb3592 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -248,6 +248,8 @@ static inline bool virtqueue_use_indirect(struct 
> virtqueue *_vq,
>  
>  static bool vring_use_dma_api(struct virtio_device *vdev)
>  {
> + struct device *dma_dev = vdev->dev.parent;
> +
>   if (!virtio_has_iommu_quirk(vdev))
>   return true;
>  
> @@ -260,7 +262,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
>* the DMA API if we're a Xen guest, which at least allows
>* all of the sensible Xen configurations to work correctly.
>*/
> - if (xen_domain())
> + if (xen_domain() && !dma_dev->dma_mem)
>   return true;
>  
>   return false;

I can see you spotted a real issue, but this is not the right fix. We
just need something a bit more flexible than xen_domain(): there are
many kinds of Xen domains on different architectures, we basically want
to enable this (return true from vring_use_dma_api) only when the xen
swiotlb is meant to be used. Does the appended patch fix the issue you
have?

---

xen: introduce xen_vring_use_dma

From: Stefano Stabellini 

Export xen_swiotlb on arm and arm64.

Use xen_swiotlb to determine when vring should use dma APIs to map the
ring: when xen_swiotlb is enabled the dma API is required. When it is
disabled, it is not required.

Reported-by: Peng Fan 
Signed-off-by: Stefano Stabellini 

diff --git a/arch/arm/include/asm/xen/swiotlb-xen.h 
b/arch/arm/include/asm/xen/swiotlb-xen.h
new file mode 100644
index 000..455ade5
--- /dev/null
+++ b/arch/arm/include/asm/xen/swiotlb-xen.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cb44aa2..8592863 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+int xen_swiotlb __read_mostly;
+
 unsigned long xen_get_swiotlb_free_pages(unsigned int order)
 {
struct memblock_region *reg;
@@ -189,6 +191,7 @@ int __init xen_mm_init(void)
struct gnttab_cache_flush cflush;
if (!xen_initial_domain())
return 0;
+   xen_swiotlb = 1;
xen_swiotlb_init(1, false);
xen_dma_ops = &xen_swiotlb_dma_ops;
 
diff --git a/arch/arm64/include/asm/xen/swiotlb-xen.h 
b/arch/arm64/include/asm/xen/swiotlb-xen.h
new file mode 100644
index 000..455ade5
--- /dev/null
+++ b/arch/arm64/include/asm/xen/swiotlb-xen.h
@@ -0,0 +1 @@
+#include 
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755..bf8badc 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -260,7 +260,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
 * the DMA API if we're a Xen guest, which at least allows
 * all of the sensible Xen configurations to work correctly.
 */
-   if (xen_domain())
+   if (xen_vring_use_dma())
return true;
 
return false;
diff --git a/include/xen/arm/swiotlb-xen.h b/include/xen/arm/swiotlb-xen.h
new file mode 100644
index 000..2aac7c4
--- /dev/null
+++ b/include/xen/arm/swiotlb-xen.h
@@ -0,0 +1,10 @@
+#ifndef _ASM_ARM_XEN_SWIOTLB_XEN_H
+#define _ASM_ARM_XEN_SWIOTLB_XEN_H
+
+#ifdef CONFIG_SWIOTLB_XEN
+extern int xen_swiotlb;
+#else
+#define xen_swiotlb (0)
+#endif
+
+#endif
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 0e21567..74a536d 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -46,4 +46,10 @@ enum xen_domain_type {
 bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
const struct bio_vec *vec2);
 
+#include 
+static inline int xen_vring_use_dma(void)
+{
+   return !!xen_swiotlb;
+}
+
 #endif /* _XEN_XEN_H */

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-deve

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 
guest-start/debianhvm.repeat fail REGR. vs. 131842
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 131842

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131842
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 131842
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131842
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 131842
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 131842
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu166609e6070fab3424510ac7292ecb585f8b80fb
baseline version:
 qemuu147923b1a901a0370f83a0f4c58ec1baffef22f0

Last test of basis   131842  2019-01-09 00:37:22 Z   13 days
Failing since131892  2019-01-09 23:37:00 Z   12 days   12 attempts
Testing same since   132316  2019-01-22 03:33:15 Z0 days1 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Aaron Lindsay 
  Aaron Lindsay 
  Aleksandar Markovic 
  Alex Bennée 
  Alex Williamson 
  Alexander Graf 
  Alexandro Sanchez Bach 
  Alexey Kardashevskiy 
  Alistair Francis 
  Andrew Jeffery 
  Anthony PERARD 
  BALATON Zoltan 
  Borislav Petkov 
  Christian Borntraeger 
  Cleber Rosa 
  Collin Walling 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel P. Berrangé 
  David Gibson 
  David Hildenbrand 
  Dongli Zhang 
  Eduardo Habkost 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Fei Li 
  Frediano Ziglio 
  Fredrik Noring 
  Gerd Hoffmann 
  Greg Kurz 
  Guenter Roeck 
  Igor Mammedov 
  Janosch Frank 
  Jian Wang 
  Joel Stanley 
  John Snow 
  Juan Quintela 
  Kashyap Chamarthy 
  Laurent Vivier 
  Laurent Vivier 
  Li Feng 
  Li Qiang 
  Marc-André Lureau 
  Mark Cave-Ayland 
  Michael Clark 
  Michael Roth 
  Michael S. Tsirkin 
  Palmer Dabbelt 
  Paolo Bonzini 
  Paul Durrant 
  Peng Hao 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Pierre Morel 
  Prasad J Pandit 
  Priit Laes 
  Remy Noel 
  Richard Henderson 
  Roman Bolshakov 
  Samuel Thibault 
  Shameer Kolothum 
  Sreejith Mohanan 
  Stefan Berger 
  Stefan Berger 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Thomas Huth

[Xen-devel] [linux-4.19 test] 132270: regressions - FAIL

flight 132270 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132270/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 129313
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 129313
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 129313
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 129313
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 129313
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 129313
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 129313
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 129313
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 129313
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 129313
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 129313
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 129313
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 129313
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
129313
 test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2 fail in 132129 REGR. vs. 
129313

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail in 132034 pass in 
132270
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat  fail pass in 132034
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
132129
 test-armhf-armhf-xl-multivcpu  5 host-ping-check-nativefail pass in 132129

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 132129 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 132129 
never pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot   fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-chec

Re: [Xen-devel] [PATCH for-4.12] xen/arm: gic: Make sure the number of interrupt lines is valid before using it

2019-01-22 Thread Stefano Stabellini

On Fri, 30 Nov 2018, Julien Grall wrote:
> GICv2 and GICv3 supports up to 1020 interrupts. However, the value computed
> from GICD_TYPER.ITLinesNumber can be up to 1024. On GICv3, we will end up to
> write in reserved registers that are right after the IROUTERs one as the
> value is not capped early enough.
> 
> Cap the number of interrupts as soon as we compute it so we know we can
> safely using it afterwards.
> 
> Signed-off-by: Julien Grall 
> Reported-by: Jan-Peter Larsson 

Reviewed-by: Stefano Stabellini 


> ---
> This patch should be backport up to Xen 4.9.

Agreed


> ---
>  xen/arch/arm/gic-v2.c | 7 ---
>  xen/arch/arm/gic-v3.c | 7 ---
>  2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 1a744c576f..e9fb8a01ab 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -353,6 +353,10 @@ static void __init gicv2_dist_init(void)
>  
>  type = readl_gicd(GICD_TYPER);
>  nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
> +/* Only 1020 interrupts are supported */
> +nr_lines = min(1020U, nr_lines);
> +gicv2_info.nr_lines = nr_lines;
> +
>  gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
>  printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
> nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
> @@ -377,9 +381,6 @@ static void __init gicv2_dist_init(void)
>  for ( i = 32; i < nr_lines; i += 32 )
>  writel_gicd(~0x0, GICD_ICENABLER + (i / 32) * 4);
>  
> -/* Only 1020 interrupts are supported */
> -gicv2_info.nr_lines = min(1020U, nr_lines);
> -
>  /* Turn on the distributor */
>  writel_gicd(GICD_CTL_ENABLE, GICD_CTLR);
>  }
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 6fbc106757..c9200d24e1 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -607,6 +607,10 @@ static void __init gicv3_dist_init(void)
>  if ( type & GICD_TYPE_LPIS )
>  gicv3_lpi_init_host_lpis(GICD_TYPE_ID_BITS(type));
>  
> +/* Only 1020 interrupts are supported */
> +nr_lines = min(1020U, nr_lines);
> +gicv3_info.nr_lines = nr_lines;
> +
>  printk("GICv3: %d lines, (IID %8.8x).\n",
> nr_lines, readl_relaxed(GICD + GICD_IIDR));
>  
> @@ -646,9 +650,6 @@ static void __init gicv3_dist_init(void)
>  
>  for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i++ )
>  writeq_relaxed(affinity, GICD + GICD_IROUTER + i * 8);
> -
> -/* Only 1020 interrupts are supported */
> -gicv3_info.nr_lines = min(1020U, nr_lines);
>  }
>  
>  static int gicv3_enable_redist(void)
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-3.18 test] 132290: regressions - FAIL

flight 132290 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132290/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 128858
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
128858
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 128858
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 128858
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 128858
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 128858
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 128858
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 128858
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-shadow 7 xen-boot fail in 132066 pass in 132290
 test-armhf-armhf-xl-vhd   7 xen-boot fail in 132066 pass in 132290
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 
132066 pass in 132290
 test-amd64-amd64-xl-shadow7 xen-boot   fail pass in 132066
 test-armhf-armhf-libvirt  7 xen-boot   fail pass in 132179

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 128858

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 132066 like 
128858
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 132066 like 
128858
 test-armhf-armhf-libvirt13 migrate-support-check fail in 132066 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 132066 never pass
 test-amd64-amd64-examine  4 memdisk-try-append   fail  like 128807
 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail like 
128807
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail  like 128841
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128858
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128858
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128858
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128858
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-su

Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain

2019-01-22 Thread Michael S. Tsirkin

On Tue, Jan 22, 2019 at 11:59:31AM -0800, Stefano Stabellini wrote:
> On Mon, 21 Jan 2019, Peng Fan wrote:
> > on i.MX8QM, M4_1 is communicating with DomU using rpmsg with a fixed
> > address as the dma mem buffer which is predefined.
> > 
> > Without this patch, the flow is:
> > vring_map_one_sg -> vring_use_dma_api
> >  -> dma_map_page
> >-> __swiotlb_map_page
> > ->swiotlb_map_page
> > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, 
> > dev_addr)), size, dir);
> > However we are using per device dma area for rpmsg, phys_to_virt
> > could not return a correct virtual address for virtual address in
> > vmalloc area. Then kernel panic.
> > 
> > With this patch, vring_use_dma_api will return false, and
> > vring_map_one_sg will return sg_phys(sg) which is the correct phys
> > address in the predefined memory region.
> > vring_map_one_sg -> vring_use_dma_api
> >  -> sg_phys(sg)
> > 
> > Signed-off-by: Peng Fan 
> > ---
> >  drivers/virtio/virtio_ring.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index cd7e755484e3..8993d7cb3592 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -248,6 +248,8 @@ static inline bool virtqueue_use_indirect(struct 
> > virtqueue *_vq,
> >  
> >  static bool vring_use_dma_api(struct virtio_device *vdev)
> >  {
> > +   struct device *dma_dev = vdev->dev.parent;
> > +
> > if (!virtio_has_iommu_quirk(vdev))
> > return true;
> >  
> > @@ -260,7 +262,7 @@ static bool vring_use_dma_api(struct virtio_device 
> > *vdev)
> >  * the DMA API if we're a Xen guest, which at least allows
> >  * all of the sensible Xen configurations to work correctly.
> >  */
> > -   if (xen_domain())
> > +   if (xen_domain() && !dma_dev->dma_mem)
> > return true;
> >  
> > return false;
> 
> I can see you spotted a real issue, but this is not the right fix. We
> just need something a bit more flexible than xen_domain(): there are
> many kinds of Xen domains on different architectures, we basically want
> to enable this (return true from vring_use_dma_api) only when the xen
> swiotlb is meant to be used. Does the appended patch fix the issue you
> have?
> 
> ---
> 
> xen: introduce xen_vring_use_dma
> 
> From: Stefano Stabellini 
> 
> Export xen_swiotlb on arm and arm64.
> 
> Use xen_swiotlb to determine when vring should use dma APIs to map the
> ring: when xen_swiotlb is enabled the dma API is required. When it is
> disabled, it is not required.
> 
> Reported-by: Peng Fan 
> Signed-off-by: Stefano Stabellini 
> 
> diff --git a/arch/arm/include/asm/xen/swiotlb-xen.h 
> b/arch/arm/include/asm/xen/swiotlb-xen.h
> new file mode 100644
> index 000..455ade5
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/swiotlb-xen.h
> @@ -0,0 +1 @@
> +#include 
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index cb44aa2..8592863 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -21,6 +21,8 @@
>  #include 
>  #include 
>  
> +int xen_swiotlb __read_mostly;
> +
>  unsigned long xen_get_swiotlb_free_pages(unsigned int order)
>  {
>   struct memblock_region *reg;
> @@ -189,6 +191,7 @@ int __init xen_mm_init(void)
>   struct gnttab_cache_flush cflush;
>   if (!xen_initial_domain())
>   return 0;
> + xen_swiotlb = 1;
>   xen_swiotlb_init(1, false);
>   xen_dma_ops = &xen_swiotlb_dma_ops;
>  
> diff --git a/arch/arm64/include/asm/xen/swiotlb-xen.h 
> b/arch/arm64/include/asm/xen/swiotlb-xen.h
> new file mode 100644
> index 000..455ade5
> --- /dev/null
> +++ b/arch/arm64/include/asm/xen/swiotlb-xen.h
> @@ -0,0 +1 @@
> +#include 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index cd7e755..bf8badc 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -260,7 +260,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
>* the DMA API if we're a Xen guest, which at least allows
>* all of the sensible Xen configurations to work correctly.
>*/
> - if (xen_domain())
> + if (xen_vring_use_dma())
>   return true;
>  
>   return false;
> diff --git a/include/xen/arm/swiotlb-xen.h b/include/xen/arm/swiotlb-xen.h
> new file mode 100644
> index 000..2aac7c4
> --- /dev/null
> +++ b/include/xen/arm/swiotlb-xen.h
> @@ -0,0 +1,10 @@
> +#ifndef _ASM_ARM_XEN_SWIOTLB_XEN_H
> +#define _ASM_ARM_XEN_SWIOTLB_XEN_H
> +
> +#ifdef CONFIG_SWIOTLB_XEN
> +extern int xen_swiotlb;
> +#else
> +#define xen_swiotlb (0)
> +#endif
> +
> +#endif
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index 0e21567..74a536d 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -46,4 +46,10 @@ enum xen_domain_type {
>  bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
>

[Xen-devel] [linux-linus test] 132374: regressions - FAIL

flight 132374 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132374/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  6 xen-install fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-saverestore.2 
fail REGR. vs. 125898

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125898
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125898
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125898
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125898
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux48b161983ae5266ffa42f0ccaf7224eaeda38e59
baseline version:
 linux94710cac0ef4ee177a63b5227664b38c95bbf703

Last test of basis   125898  2018-08-13 21:20:55 Z  162 days
Failing since125921  2018-08-15 13:06:56 Z  160 days  129 attempts
Testing same since   132374  2019-01-22 12:34:30 Z0 days1 attempts


4217 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun

[Xen-devel] Invitation to comment on Virtual I/O Device (VIRTIO) Version 1.1 - ends February 21st

2019-01-22 Thread Paul Knight

OASIS members and other interested parties,

OASIS and the OASIS Virtual I/O Device (VIRTIO) TC are pleased to announce
that Virtual I/O Device (VIRTIO) Version 1.1 is now available for public
review and comment.

Specification Overview:

This document describes the specifications of the “virtio” family of
devices. These  devices are found in virtual environments, yet by design
they look like physical devices to the guest within the virtual machine -
and this document treats them as such. This similarity allows the guest to
use standard drivers and discovery mechanisms. The purpose of virtio and
this specification is that virtual environments and guests should have a
straightforward, efficient, standard and extensible mechanism for virtual
devices, rather than boutique per-environment or per-OS mechanisms.

The documents and related files are available here:

Virtual I/O Device (VIRTIO) Version 1.1
Committee Specification Draft 01 / Public Review Draft 01
20 December 2018

Editable source (Authoritative):
https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/tex/
HTML:
https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html
PDF:
https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf

Example driver listing:
https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/listings/

For your convenience, OASIS provides a complete package of the
specification document and any related files in ZIP distribution files. You
can download the ZIP file at:
https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.zip

How to Provide Feedback

OASIS and the OASIS Virtual I/O Device (VIRTIO) TC value your feedback. We
solicit input from developers, users and others, whether OASIS members or
not, for the sake of improving the interoperability and quality of its
technical work.

The public review starts 23 January 2019 at 00:00 UTC and ends 21 February
2019 at 23:59 UTC.

Comments may be submitted to the TC by any person through the use of the
OASIS TC Comment Facility which can be used by following the instructions
on the TC's "Send A Comment" page (
https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio).

Comments submitted by TC non-members for this work and for other work of
this TC are publicly archived and can be viewed at:

https://lists.oasis-open.org/archives/virtio-comment/

All comments submitted to OASIS are subject to the OASIS Feedback License,
which ensures that the feedback you provide carries the same obligations at
least as the obligations of the TC members. In connection with this public
review, we call your attention to the OASIS IPR Policy [1] applicable
especially [2] to the work of this technical committee. All members of the
TC should be familiar with this document, which may create obligations
regarding the disclosure and availability of a member's patent, copyright,
trademark and license rights that read on an approved OASIS specification.

OASIS invites any persons who know of any such claims to disclose these if
they may be essential to the implementation of the above specification, so
that notice of them may be posted to the notice page for this TC's work.

Additional information about the specification and the VIRTIO TC can be
found at the TC's public home page:
https://www.oasis-open.org/committees/virtio/

== Additional references:

[1] https://www.oasis-open.org/policies-guidelines/ipr

[2] https://www.oasis-open.org/committees/virtio/ipr.php
https://www.oasis-open.org/policies-guidelines/ipr#Non-Assertion-Mode
Non-Assertion Mode
-- 
Paul Knight   - Tel: +1 781-883-1783
OASIS  - Advancing open standards for the
information society - Document Process Analyst

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain

2019-01-22 Thread h...@infradead.org

On Tue, Jan 22, 2019 at 11:59:31AM -0800, Stefano Stabellini wrote:
> > if (!virtio_has_iommu_quirk(vdev))
> > return true;
> >  
> > @@ -260,7 +262,7 @@ static bool vring_use_dma_api(struct virtio_device 
> > *vdev)
> >  * the DMA API if we're a Xen guest, which at least allows
> >  * all of the sensible Xen configurations to work correctly.
> >  */
> > -   if (xen_domain())
> > +   if (xen_domain() && !dma_dev->dma_mem)
> > return true;
> >  
> > return false;
> 
> I can see you spotted a real issue, but this is not the right fix. We
> just need something a bit more flexible than xen_domain(): there are
> many kinds of Xen domains on different architectures, we basically want
> to enable this (return true from vring_use_dma_api) only when the xen
> swiotlb is meant to be used. Does the appended patch fix the issue you
> have?

The problem generally is the other way around - if dma_dev->dma_mem
is set the device decription in the device tree explicitly requires
using this memory, so we must _always_ use the DMA API.

The problem is just that that rproc driver absuses the DMA API
in horrible ways.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 132382: regressions - FAIL