<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/xen, branch v4.4.293</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.293</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.293'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2021-02-23T12:58:14Z</updated>
<entry>
<title>Xen/gntdev: correct error checking in gntdev_map_grant_pages()</title>
<updated>2021-02-23T12:58:14Z</updated>
<author>
<name>Jan Beulich</name>
<email>jbeulich@suse.com</email>
</author>
<published>2021-02-15T07:52:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=71ed732b5725b3a2e36694644ce8ccdf7d9918e8'/>
<id>urn:sha1:71ed732b5725b3a2e36694644ce8ccdf7d9918e8</id>
<content type='text'>
commit ebee0eab08594b2bd5db716288a4f1ae5936e9bc upstream.

Failure of the kernel part of the mapping operation should also be
indicated as an error to the caller, or else it may assume the
respective kernel VA is okay to access.

Furthermore gnttab_map_refs() failing still requires recording
successfully mapped handles, so they can be unmapped subsequently. This
in turn requires there to be a way to tell full hypercall failure from
partial success - preset map_op status fields such that they won't
"happen" to look as if the operation succeeded.

Also again use GNTST_okay instead of implying its value (zero).

This is part of XSA-361.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen/xenbus: Count pending messages for each watch</title>
<updated>2020-12-29T12:42:45Z</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:07:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=df3367c1cb5e1a6d8a527d651f2163756c81c116'/>
<id>urn:sha1:df3367c1cb5e1a6d8a527d651f2163756c81c116</id>
<content type='text'>
commit 3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc upstream.

This commit adds a counter of pending messages for each watch in the
struct.  It is used to skip unnecessary pending messages lookup in
'unregister_xenbus_watch()'.  It could also be used in 'will_handle'
callback.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path()</title>
<updated>2020-12-29T12:42:45Z</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:04:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=aafb4352cba47df628649983d93d14dee5527f1d'/>
<id>urn:sha1:aafb4352cba47df628649983d93d14dee5527f1d</id>
<content type='text'>
commit 2e85d32b1c865bec703ce0c962221a5e955c52c2 upstream.

Some code does not directly make 'xenbus_watch' object and call
'register_xenbus_watch()' but use 'xenbus_watch_path()' instead.  This
commit adds support of 'will_handle' callback in the
'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>xen/xenbus: Allow watches discard events before queueing</title>
<updated>2020-12-29T12:42:45Z</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:02:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=de66402f45c0cae9566b1568cc1b2df2b5ccbbf8'/>
<id>urn:sha1:de66402f45c0cae9566b1568cc1b2df2b5ccbbf8</id>
<content type='text'>
commit fed1755b118147721f2c87b37b9d66e62c39b668 upstream.

If handling logics of watch events are slower than the events enqueue
logic and the events can be created from the guests, the guests could
trigger memory pressure by intensively inducing the events, because it
will create a huge number of pending events that exhausting the memory.

Fortunately, some watch events could be ignored, depending on its
handler callback.  For example, if the callback has interest in only one
single path, the watch wouldn't want multiple pending events.  Or, some
watches could ignore events to same path.

To let such watches to volutarily help avoiding the memory pressure
situation, this commit introduces new watch callback, 'will_handle'.  If
it is not NULL, it will be called for each new event just before
enqueuing it.  Then, if the callback returns false, the event will be
discarded.  No watch is using the callback for now, though.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>xen/events: add a new "late EOI" evtchn framework</title>
<updated>2020-11-18T17:25:02Z</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2020-11-03T16:22:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1d762cb6676b5f9c57c6ac56856e540529a8d928'/>
<id>urn:sha1:1d762cb6676b5f9c57c6ac56856e540529a8d928</id>
<content type='text'>
commit 54c9de89895e0a36047fcc4ae754ea5b8655fb9d upstream.

In order to avoid tight event channel related IRQ loops add a new
framework of "late EOI" handling: the IRQ the event channel is bound
to will be masked until the event has been handled and the related
driver is capable to handle another event. The driver is responsible
for unmasking the event channel via the new function xen_irq_lateeoi().

This is similar to binding an event channel to a threaded IRQ, but
without having to structure the driver accordingly.

In order to support a future special handling in case a rogue guest
is sending lots of unsolicited events, add a flag to xen_irq_lateeoi()
which can be set by the caller to indicate the event was a spurious
one.

This is part of XSA-332.

Cc: stable@vger.kernel.org
Reported-by: Julien Grall &lt;julien@xen.org&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Reviewed-by: Wei Liu &lt;wl@xen.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fix xen_swiotlb_dma_mmap prototype</title>
<updated>2017-10-05T07:41:48Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-10-04T13:51:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=228969b4764fe2b0f58ef096f63666196f7b4881'/>
<id>urn:sha1:228969b4764fe2b0f58ef096f63666196f7b4881</id>
<content type='text'>
xen_swiotlb_dma_mmap was backported from v4.10, but older
kernels before commit 00085f1efa38 ("dma-mapping: use unsigned long
for dma_attrs") use a different signature:

arm/xen/mm.c:202:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .mmap = xen_swiotlb_dma_mmap,
          ^~~~~~~~~~~~~~~~~~~~
arm/xen/mm.c:202:10: note: (near initialization for 'xen_swiotlb_dma_ops.mmap')

This adapts the patch to the old calling conventions.

Fixes: "swiotlb-xen: implement xen_swiotlb_dma_mmap callback"
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>swiotlb-xen: implement xen_swiotlb_dma_mmap callback</title>
<updated>2017-10-05T07:41:48Z</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefano.stabellini@eu.citrix.com</email>
</author>
<published>2017-02-07T17:58:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=079c03f4a915da1279604f88d6c07bf70427ddbc'/>
<id>urn:sha1:079c03f4a915da1279604f88d6c07bf70427ddbc</id>
<content type='text'>
commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.

This function creates userspace mapping for the DMA-coherent memory.

Signed-off-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Signed-off-by: Oleksandr Dmytryshyn &lt;oleksandr.dmytryshyn@globallogic.com&gt;
Signed-off-by: Andrii Anisov &lt;andrii_anisov@epam.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen: Fix page &lt;-&gt; pfn conversion on 32 bit systems</title>
<updated>2016-05-11T09:21:14Z</updated>
<author>
<name>Ross Lagerwall</name>
<email>ross.lagerwall@citrix.com</email>
</author>
<published>2016-03-17T16:51:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0f7ea0699ac02fb7c5d67e8eac8f8581912f4988'/>
<id>urn:sha1:0f7ea0699ac02fb7c5d67e8eac8f8581912f4988</id>
<content type='text'>
commit 60901df3aed230d4565dca003f11b6a95fbf30d9 upstream.

Commit 1084b1988d22dc165c9dbbc2b0e057f9248ac4db (xen: Add Xen specific
page definition) caused a regression in 4.4.

The xen functions to convert between pages and pfns fail due to an
overflow on systems where a physical address may not fit in an
unsigned long (e.g. x86 32 bit PAE systems). Rework the conversion to
avoid overflow. This should also result in simpler object code.

This bug manifested itself as disk corruption with Linux 4.4 when
using blkfront in a Xen HVM x86 32 bit guest with more than 4 GiB of
memory.

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen: Add RING_COPY_REQUEST()</title>
<updated>2015-12-18T15:00:17Z</updated>
<author>
<name>David Vrabel</name>
<email>david.vrabel@citrix.com</email>
</author>
<published>2015-10-30T14:58:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=454d5d882c7e412b840e3c99010fe81a9862f6fb'/>
<id>urn:sha1:454d5d882c7e412b840e3c99010fe81a9862f6fb</id>
<content type='text'>
Using RING_GET_REQUEST() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected).  Safe usage of a request
generally requires taking a local copy.

Provide a RING_COPY_REQUEST() macro to use instead of
RING_GET_REQUEST() and an open-coded memcpy().  This takes care of
ensuring that the copy is done correctly regardless of any possible
compiler optimizations.

Use a volatile source to prevent the compiler from reordering or
omitting the copy.

This is part of XSA155.

CC: stable@vger.kernel.org
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
</content>
</entry>
<entry>
<title>xen/grant-table: Add an helper to iterate over a specific number of grants</title>
<updated>2015-10-23T13:20:46Z</updated>
<author>
<name>Julien Grall</name>
<email>julien.grall@citrix.com</email>
</author>
<published>2015-10-13T16:50:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f73314b28148f9ee9f89a0ae961c8fb36e3269fa'/>
<id>urn:sha1:f73314b28148f9ee9f89a0ae961c8fb36e3269fa</id>
<content type='text'>
With the 64KB page granularity support on ARM64, a Linux page may be
split accross multiple grant.

Currently we have the helper gnttab_foreach_grant_in_grant to break a
Linux page based on an offset and a len, but it doesn't fit when we only
have a number of grants in hand.

Introduce a new helper which take an array of Linux page and a number of
grant and will figure out the address of each grant.

Signed-off-by: Julien Grall &lt;julien.grall@citrix.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
</content>
</entry>
</feed>
