Re: 答复: [PATCH] virtio_net: reduce raw_smp_processor_id() calling in virtnet_xdp_get_sq

[Michael S. Tsirkin]

On Tue, Aug 31, 2021 at 02:09:36AM +, Li,Rongqing wrote:
> > -邮件原件-
> > 发件人: Michael S. Tsirkin 
> > 发送时间: 2021年8月31日 5:10
> > 收件人: Li,Rongqing 
> > 抄送: net...@vger.kernel.org; b...@vger.kernel.org;
> > virtualization@lists.linux-foundation.org
> > 主题: Re: [PATCH] virtio_net: reduce raw_smp_processor_id() calling in
> > virtnet_xdp_get_sq
> > 
> > On Thu, Aug 26, 2021 at 04:21:35PM +0800, Li RongQing wrote:
> > > smp_processor_id()/raw* will be called once each when not more queues
> > > in virtnet_xdp_get_sq() which is called in non-preemptible context, so
> > > it's safe to call the function
> > > smp_processor_id() once.
> > >
> > > Signed-off-by: Li RongQing 
> > 
> > commit log should probably explain why it's a good idea to replace
> > raw_smp_processor_id with smp_processor_id in the case of curr_queue_pairs
> > <= nr_cpu_ids.
> > 
> 
> 
> I change it as below, is it ok?
> 
> virtio_net: reduce raw_smp_processor_id() calling in virtnet_xdp_get_sq

shorter:

virtio_net: s/raw_smp_processor_id/smp_processor_id/ in virtnet_xdp_get_sq


> 
> smp_processor_id() and raw_smp_processor_id() are called once
> each in virtnet_xdp_get_sq(), when curr_queue_pairs <= nr_cpu_ids,
> should be merged

I'd just drop this part.

> 
> virtnet_xdp_get_sq() is called in non-preemptible context, so
> it's safe to call the function smp_processor_id(), and keep
> smp_processor_id(), and remove the calling of raw_smp_processor_id(),
> avoid the wrong use virtnet_xdp_get_sq to preemptible context
> in the future

s/avoid.*/this way we'll get a warning if this is ever called in a preemptible 
context/


> 
> -Li

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V4 0/5] virtio: Add virtio-device bindings

[Michael S. Tsirkin]

On Tue, Aug 31, 2021 at 11:01:05AM +0530, Viresh Kumar wrote:
> On 27-07-21, 10:53, Viresh Kumar wrote:
> > Hi,
> > 
> > Currently the DT only provides support for following node types for 
> > virtio-mmio
> > nodes:
> > 
> > virtio_mmio@a00 {
> > dma-coherent;
> > interrupts = <0x00 0x10 0x01>;
> > reg = <0x00 0xa00 0x00 0x200>;
> > compatible = "virtio,mmio";
> > };
> > 
> > Here, each virtio-mmio corresponds to a virtio-device. But there is no way 
> > for
> > other users in the DT to show their dependency on virtio devices.
> > 
> > This patchset provides that support.
> > 
> > The first patch adds virtio-device bindings to allow for device sub-nodes 
> > to be
> > present and the second patch updates the virtio core to update the of_node.
> > 
> > Other patches add bindings for i2c and gpio devices.
> > 
> > Tested on x86 with qemu for arm64.
> 
> Michael, are you picking these up for 5.15 ?

Okay.

> -- 
> viresh

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC PATCH 0/3] drivers/net/virtio_net: Added RSS support.

[Andrew Melnichenko]

Hi guys,
Can you please review possible virtio-net driver RSS support?
Do you have any comments or proposals?

On Wed, Aug 18, 2021 at 8:55 PM Andrew Melnychenko 
wrote:

> This series of RFC patches for comments and additional proposals.
>
> Virtio-net supports "hardware" RSS with toeplitz key.
> Also, it allows receiving calculated hash in vheader
> that may be used with RPS.
> Added ethtools callbacks to manipulate RSS.
>
> Technically hash calculation may be set only for
> SRC+DST and SRC+DST+PORTSRC+PORTDST hashflows.
> The completely disabling hash calculation for TCP or UDP
> would disable hash calculation for IP.
>
> RSS/RXHASH is disabled by default.
>
> Andrew Melnychenko (3):
>   drivers/net/virtio_net: Fixed vheader to use v1.
>   drivers/net/virtio_net: Added basic RSS support.
>   drivers/net/virtio_net: Added RSS hash report.
>
>  drivers/net/virtio_net.c | 402 +--
>  1 file changed, 385 insertions(+), 17 deletions(-)
>
> --
> 2.31.1
>
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

ICITS'22 | Costa Rica | Deadline: September 13

[ML]

ICITS'22 - The 2022 International Conference on Information Technology & Systems
San Carlos, Costa Rica, 9 - 11 February 2022
http://icits.me 


SCOPE

ICITS'22 - The 2022 International Conference on Information Technology & 
Systems (http://icits.me ), to be held in Tecnológico de 
Costa Rica, Campus de San Carlos, Costa Rica, 9 - 11 February 2022, is an 
international forum for researchers and practitioners to present and discuss 
the most recent innovations, trends, results, experiences and concerns in the 
several perspectives of Information Technology & Systems.

We are pleased to invite you to submit your papers to ICITS'22. They can be 
written in English, Spanish or Portuguese. All submissions will be reviewed on 
the basis of relevance, originality, importance and clarity.


TOPICS

Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Ethics, Computers and Security (ECS)
K) Health Informatics (HIS);
L) Information Technologies in Education (ITE);
M) Media, Applied Technology and Communication (MATC).


SUBMISSION and DECISION

Submitted papers written in English (until 10-page limit) must comply with the 
format of the Lecture Notes in Networks and Systems series (see Instructions 
for Authors at Springer Website), must not have been published before, not be 
under review for any other conference or publication and not include any 
information leading to the authors’ identification. Therefore, the authors’ 
names and affiliations should not be included in the version for evaluation by 
the Scientific Committee. This information should only be included in the 
camera-ready version, saved in Word or Latex format and also in PDF format. 
These files must be accompanied by the Consent to Publish form filled out, in a 
ZIP file, and uploaded at the conference management system.
Submitted papers written in Spanish or Portuguese (until 15-page limit) must 
comply with the format of RISTI - Revista Ibérica de Sistemas e Tecnologias de 
Informação (download instructions/template for authors in Spanish or 
Portuguese), must not have been published before, not be under review for any 
other conference or publication and not include any information leading to the 
authors’ identification. Therefore, the authors’ names and affiliations should 
not be included in the version for evaluation by the Scientific Committee. This 
information should only be included in the camera-ready version, saved in Word. 
These files must be uploaded at the conference management system in a ZIP file.
All papers will be subjected to a “double-blind review” by at least two members 
of the Scientific Committee.
Based on Scientific Committee evaluation, a paper can be rejected or accepted 
by the Conference Chairs. In the later case, it can be accepted as paper or 
poster.
The authors of papers accepted as posters must build and print a poster to be 
exhibited during the Conference. This poster must follow an A1 or A2 vertical 
format. The Conference can include Work Sessions where these posters are 
presented and orally discussed, with a 7 minute limit per poster.
The authors of accepted papers will have 15 minutes to present their work in a 
Conference Work Session; approximately 5 minutes of discussion will follow each 
presentation.


PUBLICATION and INDEXING

Papers accepted as posters are not published; they are only exhibited, 
presented and discussed during the conference.

To ensure that a paper accepted as paper is published, at least one of the 
authors must be fully registered by the 5th of November 2021, and the paper 
must comply with the suggested layout and page-limit. Additionally, all 
recommended changes must be addressed by the authors before they submit the 
camera-ready version.
No more than one paper per registration will be published. An extra fee must be 
paid for publication of additional papers, with a maximum of one additional 
paper per registration. One registration permits only the participation of one 
author in the conference.

Papers written in English and accepted and registered will be published in 
Proceedings by Springer, in a book of the Lecture Notes in Networks and Systems 
series, will  be submitted for indexation by SCOPUS, WoS, 

Re: [PATCH v4 0/6] Add support for control VQ and multique

[Michael S. Tsirkin]

On Mon, Aug 23, 2021 at 08:21:17AM +0300, Eli Cohen wrote:
> This series adds support for control virtqueue.
> patch 1: A simple cleanup.
> patch 2: Modify functions to pass struct struct mlx5_vdpa_dev which
>  holds information requried in subsequent patches.
> patch 3: Save the callbacks of virtqueue in its own array and not on
>  struct mlx5_vdpa_virtqueue. Needed to avoid issue in qemu.
> patch 4: Enforce valid indices based on negtiated features.
> patch 5: Support multique and MAC modification
> patch 6: Add multiqueue support

Eli I don't know what went wrong but it looks like this patchset never actually
reached the virtualization@lists.linux-foundation.org mailing list.

See e.g. 
https://lore.kernel.org/virtualization/ad10d3ea-24c1-7f18-630d-be9f2bf0b...@redhat.com/

I tried bouncing it which maybe will fix it, we'll see.


> v3 -> v4:
> make some functions static in the file
> 
> Eli Cohen (6):
>   vdpa/mlx5: Remove redundant header file inclusion
>   vdpa/mlx5: function prototype modifications in preparation to control
> VQ
>   vdpa/mlx5: Decouple virtqueue callback from struct mlx5_vdpa_virtqueue
>   vdpa/mlx5: Ensure valid indices are provided
>   vdpa/mlx5: Add support for control VQ and MAC setting
>   vdpa/mlx5: Add multiqueue support
> 
>  drivers/vdpa/mlx5/core/mlx5_vdpa.h |  26 +-
>  drivers/vdpa/mlx5/core/mr.c|  81 +++--
>  drivers/vdpa/mlx5/core/resources.c |  35 ++
>  drivers/vdpa/mlx5/net/mlx5_vnet.c  | 517 +
>  4 files changed, 575 insertions(+), 84 deletions(-)
> 
> -- 
> 2.31.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v13 02/13] eventfd: Export eventfd_wake_count to modules

[Jason Wang]

在 2021/8/31 下午6:36, Xie Yongji 写道:

Export eventfd_wake_count so that some modules can use
the eventfd_signal_count() to check whether the
eventfd_signal() call should be deferred to a safe context.

Signed-off-by: Xie Yongji 



And this matches the comment inside eventfd_signal():

    /*
 * Deadlock or stack overflow issues can happen if we recurse here
 * through waitqueue wakeup handlers. If the caller users 
potentially

 * nested waitqueues with custom wakeup handlers, then it should
 * check eventfd_signal_count() before calling this function. If
 * it returns true, the eventfd_signal() call should be 
deferred to a

 * safe context.
 */


So:

Acked-by: Jason Wang 



---
  fs/eventfd.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/fs/eventfd.c b/fs/eventfd.c
index e265b6dd4f34..1b3130b8d6c1 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -26,6 +26,7 @@
  #include 
  
  DEFINE_PER_CPU(int, eventfd_wake_count);

+EXPORT_PER_CPU_SYMBOL_GPL(eventfd_wake_count);
  
  static DEFINE_IDA(eventfd_ida);
  


___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [virtio-comment] [PATCH v5] virtio-vsock: add description for datagram type

[Michael S. Tsirkin]

On Thu, Jun 10, 2021 at 06:12:03PM +, Jiang Wang wrote:
> Add supports for datagram type for virtio-vsock. Datagram
> sockets are connectionless and unreliable. To avoid contention
> with stream and other sockets, add two more virtqueues and
> a new feature bit to identify if those two new queues exist or not.
> 
> Also add descriptions for resource management of datagram, which
> does not use the existing credit update mechanism associated with
> stream sockets.
> 
> Signed-off-by: Jiang Wang 

Is this going anywhere? Linux with this included was just released but
if no one has the cycles to work on the spec then it's not too late to
disable the guest code in a stable@ patch.

> ---
> 
> V2: addressed the comments for the previous version.
> V3: add description for the mergeable receive buffer.
> V4: add a feature bit for stream and reserver a bit for seqpacket.
> Fix mrg_rxbuf related sentences.
> V5: removed mergeable rx buffer part. It will go to a 
> separate patch. Fixed comments about tx, rx, feature bit etc.
> 
>  virtio-vsock.tex | 71 
> +++-
>  1 file changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/virtio-vsock.tex b/virtio-vsock.tex
> index da7e641..26a62ac 100644
> --- a/virtio-vsock.tex
> +++ b/virtio-vsock.tex
> @@ -9,14 +9,37 @@ \subsection{Device ID}\label{sec:Device Types / Socket 
> Device / Device ID}
>  
>  \subsection{Virtqueues}\label{sec:Device Types / Socket Device / Virtqueues}
>  \begin{description}
> -\item[0] rx
> -\item[1] tx
> +\item[0] stream rx
> +\item[1] stream tx
> +\item[2] datagram rx
> +\item[3] datagram tx
> +\item[4] event
> +\end{description}
> +The virtio socket device uses 5 queues if feature bit VIRTIO_VSOCK_F_DRGAM 
> is set. Otherwise, it
> +only uses 3 queues, as the following.
> +
> +\begin{description}
> +\item[0] stream rx
> +\item[1] stream tx
>  \item[2] event
>  \end{description}
>  
> +When behavior differs between stream and datagram rx/tx virtqueues
> +their full names are used. Common behavior is simply described in
> +terms of rx/tx virtqueues and applies to both stream and datagram
> +virtqueues.
> +
>  \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature 
> bits}
>  
> -There are currently no feature bits defined for this device.
> +\begin{description}
> +\item[VIRTIO_VSOCK_F_STREAM (0)] Device has support for stream socket type.
> +\end{description}
> +
> +\begin{description}
> +\item[VIRTIO_VSOCK_F_DGRAM (2)] Device has support for datagram socket type.
> +\end{description}
> +
> +If no feature bits are defined, assume device only supports stream socket 
> type.
>  
>  \subsection{Device configuration layout}\label{sec:Device Types / Socket 
> Device / Device configuration layout}
>  
> @@ -107,6 +130,9 @@ \subsection{Device Operation}\label{sec:Device Types / 
> Socket Device / Device Op
>  
>  \subsubsection{Virtqueue Flow Control}\label{sec:Device Types / Socket 
> Device / Device Operation / Virtqueue Flow Control}
>  
> +Flow control applies to stream sockets; datagram sockets do not have
> +flow control.
> +
>  The tx virtqueue carries packets initiated by applications and replies to
>  received packets.  The rx virtqueue carries packets initiated by the device 
> and
>  replies to previously transmitted packets.
> @@ -140,12 +166,15 @@ \subsubsection{Addressing}\label{sec:Device Types / 
> Socket Device / Device Opera
>  consists of a (cid, port number) tuple. The header fields used for this are
>  \field{src_cid}, \field{src_port}, \field{dst_cid}, and \field{dst_port}.
>  
> -Currently only stream sockets are supported. \field{type} is 1 for stream
> -socket types.
> +Currently stream and datagram (dgram) sockets are supported. \field{type} is 
> 1 for stream
> +socket types. \field{type} is 3 for dgram socket types.
>  
>  Stream sockets provide in-order, guaranteed, connection-oriented delivery
>  without message boundaries.
>  
> +Datagram sockets provide unordered, unreliable, connectionless messages 
> +with message boundaries and a maximum length.
> +
>  \subsubsection{Buffer Space Management}\label{sec:Device Types / Socket 
> Device / Device Operation / Buffer Space Management}
>  \field{buf_alloc} and \field{fwd_cnt} are used for buffer space management of
>  stream sockets. The guest and the device publish how much buffer space is
> @@ -162,7 +191,7 @@ \subsubsection{Buffer Space Management}\label{sec:Device 
> Types / Socket Device /
>  u32 peer_free = peer_buf_alloc - (tx_cnt - peer_fwd_cnt);
>  \end{lstlisting}
>  
> -If there is insufficient buffer space, the sender waits until virtqueue 
> buffers
> +For stream sockets, if there is insufficient buffer space, the sender waits 
> until virtqueue buffers
>  are returned and checks \field{buf_alloc} and \field{fwd_cnt} again. Sending
>  the VIRTIO_VSOCK_OP_CREDIT_REQUEST packet queries how much buffer space is
>  available. The reply to this query is a VIRTIO_VSOCK_OP_CREDIT_UPDATE 

Re: [External] Re: [virtio-comment] [PATCH v5] virtio-vsock: add description for datagram type

[Jiang Wang .]

On Tue, Aug 31, 2021 at 6:13 PM Michael S. Tsirkin  wrote:
>
> On Thu, Jun 10, 2021 at 06:12:03PM +, Jiang Wang wrote:
> > Add supports for datagram type for virtio-vsock. Datagram
> > sockets are connectionless and unreliable. To avoid contention
> > with stream and other sockets, add two more virtqueues and
> > a new feature bit to identify if those two new queues exist or not.
> >
> > Also add descriptions for resource management of datagram, which
> > does not use the existing credit update mechanism associated with
> > stream sockets.
> >
> > Signed-off-by: Jiang Wang 
>
> Is this going anywhere? Linux with this included was just released but
> if no one has the cycles to work on the spec then it's not too late to
> disable the guest code in a stable@ patch.
>

Hi Michael,

I am still working on this (fixing the migration issue), but would
like to know if there are any more
comments or not.  I did not notice any commits related to vsock
dgram merged to Linux kernel, could you show me the commit link?

Thanks and regards,

Jiang

> > ---
> >
> > V2: addressed the comments for the previous version.
> > V3: add description for the mergeable receive buffer.
> > V4: add a feature bit for stream and reserver a bit for seqpacket.
> > Fix mrg_rxbuf related sentences.
> > V5: removed mergeable rx buffer part. It will go to a
> > separate patch. Fixed comments about tx, rx, feature bit etc.
> >
> >  virtio-vsock.tex | 71 
> > +++-
> >  1 file changed, 60 insertions(+), 11 deletions(-)
> >
> > diff --git a/virtio-vsock.tex b/virtio-vsock.tex
> > index da7e641..26a62ac 100644
> > --- a/virtio-vsock.tex
> > +++ b/virtio-vsock.tex
> > @@ -9,14 +9,37 @@ \subsection{Device ID}\label{sec:Device Types / Socket 
> > Device / Device ID}
> >
> >  \subsection{Virtqueues}\label{sec:Device Types / Socket Device / 
> > Virtqueues}
> >  \begin{description}
> > -\item[0] rx
> > -\item[1] tx
> > +\item[0] stream rx
> > +\item[1] stream tx
> > +\item[2] datagram rx
> > +\item[3] datagram tx
> > +\item[4] event
> > +\end{description}
> > +The virtio socket device uses 5 queues if feature bit VIRTIO_VSOCK_F_DRGAM 
> > is set. Otherwise, it
> > +only uses 3 queues, as the following.
> > +
> > +\begin{description}
> > +\item[0] stream rx
> > +\item[1] stream tx
> >  \item[2] event
> >  \end{description}
> >
> > +When behavior differs between stream and datagram rx/tx virtqueues
> > +their full names are used. Common behavior is simply described in
> > +terms of rx/tx virtqueues and applies to both stream and datagram
> > +virtqueues.
> > +
> >  \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature 
> > bits}
> >
> > -There are currently no feature bits defined for this device.
> > +\begin{description}
> > +\item[VIRTIO_VSOCK_F_STREAM (0)] Device has support for stream socket type.
> > +\end{description}
> > +
> > +\begin{description}
> > +\item[VIRTIO_VSOCK_F_DGRAM (2)] Device has support for datagram socket 
> > type.
> > +\end{description}
> > +
> > +If no feature bits are defined, assume device only supports stream socket 
> > type.
> >
> >  \subsection{Device configuration layout}\label{sec:Device Types / Socket 
> > Device / Device configuration layout}
> >
> > @@ -107,6 +130,9 @@ \subsection{Device Operation}\label{sec:Device Types / 
> > Socket Device / Device Op
> >
> >  \subsubsection{Virtqueue Flow Control}\label{sec:Device Types / Socket 
> > Device / Device Operation / Virtqueue Flow Control}
> >
> > +Flow control applies to stream sockets; datagram sockets do not have
> > +flow control.
> > +
> >  The tx virtqueue carries packets initiated by applications and replies to
> >  received packets.  The rx virtqueue carries packets initiated by the 
> > device and
> >  replies to previously transmitted packets.
> > @@ -140,12 +166,15 @@ \subsubsection{Addressing}\label{sec:Device Types / 
> > Socket Device / Device Opera
> >  consists of a (cid, port number) tuple. The header fields used for this are
> >  \field{src_cid}, \field{src_port}, \field{dst_cid}, and \field{dst_port}.
> >
> > -Currently only stream sockets are supported. \field{type} is 1 for stream
> > -socket types.
> > +Currently stream and datagram (dgram) sockets are supported. \field{type} 
> > is 1 for stream
> > +socket types. \field{type} is 3 for dgram socket types.
> >
> >  Stream sockets provide in-order, guaranteed, connection-oriented delivery
> >  without message boundaries.
> >
> > +Datagram sockets provide unordered, unreliable, connectionless messages
> > +with message boundaries and a maximum length.
> > +
> >  \subsubsection{Buffer Space Management}\label{sec:Device Types / Socket 
> > Device / Device Operation / Buffer Space Management}
> >  \field{buf_alloc} and \field{fwd_cnt} are used for buffer space management 
> > of
> >  stream sockets. The guest and the device publish how much buffer space is
> > @@ -162,7 +191,7 @@ \subsubsection{Buffer Space 
> > 

[PATCH v3 0/3] virtio-mem: disallow mapping virtio-mem memory via /dev/mem

[David Hildenbrand]

I think this might be a good fit for the -mm tree, as the actual virtio-mem
changes are rather small.

--

Let's add the basic infrastructure to exclude some physical memory
regions marked as "IORESOURCE_SYSTEM_RAM" completely from /dev/mem access,
even though they are not marked IORESOURCE_BUSY and even though
"iomem=relaxed" is set. Resource IORESOURCE_EXCLUSIVE for that purpose
instead of adding new flags to express something similar to
"soft-busy" or "not busy yet, but already prepared by a driver and not
to be mapped by user space".

Use it for virtio-mem, to disallow mapping any virtio-mem memory via
/dev/mem to user space after the virtio-mem driver was loaded.

Details can be found in patch #2 and #3.

v2 -> v3:
- "kernel/resource: clean up and optimize iomem_is_exclusive()"
-- Reshuffled and moved for_each_resource() etc. into this patch
- "kernel/resource: disallow access to exclusive system RAM regions"
-- Leave CONFIG_STRICT_DEVMEM=n alone. Hoog into iomem_is_exclusive()
   instead.
-- Improve comments
- "virtio-mem: disallow mapping virtio-mem memory via /dev/mem"
-- Don't allow building virtio_mem without CONFIG_STRICT_DEVMEM when we
   have CONFIG_DEVMEM, where we don't have any guarantees.
- Rework all patch descriptions

v1 -> v2:
- "/dev/mem: disallow access to explicitly excluded system RAM regions"
-- Introduce and use for_each_resource() and next_resource_skip_children()
-- s/iomem_range_contains_excluded/iomem_range_contains_excluded_devmem/
- "kernel/resource: cleanup and optimize iomem_is_exclusive()"
-- Use for_each_resource()

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: "Rafael J. Wysocki" 
Cc: Andrew Morton 
Cc: Dan Williams 
Cc: Hanjun Guo 
Cc: Andy Shevchenko 
Cc: virtualization@lists.linux-foundation.org
Cc: linux...@kvack.org

David Hildenbrand (3):
  kernel/resource: clean up and optimize iomem_is_exclusive()
  kernel/resource: disallow access to exclusive system RAM regions
  virtio-mem: disallow mapping virtio-mem memory via /dev/mem

 drivers/virtio/Kconfig  |  1 +
 drivers/virtio/virtio_mem.c |  4 ++-
 kernel/resource.c   | 54 ++---
 3 files changed, 43 insertions(+), 16 deletions(-)


base-commit: 7d2a07b769330c34b4deabeed939325c77a7ec2f
-- 
2.31.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [GIT PULL] virtio: a last minute fix

[David Hildenbrand]

On 29.08.21 20:11, Linus Torvalds wrote:

On Sun, Aug 29, 2021 at 8:53 AM Michael S. Tsirkin  wrote:


Donnu if it's too late - was on vacation and this only arrived
Wednesday. Seems to be necessary to avoid introducing a regression
in virtio-mem.


Heh. Not too late for 5.14, but too late in the sense that I had
picked this one up manually already as commit 425bec0032f5
("virtio-mem: fix sleeping in RCU read side section in
virtio_mem_online_page_cb()").


Thanks Michael for sending this last minute and thanks Linus for picking 
it up independently early! Awesome :)


--
Thanks,

David / dhildenb

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/1] virtio-blk: avoid preallocating big SGL for data

[Feng Li]

Does this hurt the performance of virtio-blk?
I think a fio result is needed here.

On Tue, Aug 31, 2021 at 7:36 AM Max Gurtovoy  wrote:
>
> No need to pre-allocate a big buffer for the IO SGL anymore. If a device
> has lots of deep queues, preallocation for the sg list can consume
> substantial amounts of memory. For HW virtio-blk device, nr_hw_queues
> can be 64 or 128 and each queue's depth might be 128. This means the
> resulting preallocation for the data SGLs is big.
>
> Switch to runtime allocation for SGL for lists longer than 2 entries.
> This is the approach used by NVMe drivers so it should be reasonable for
> virtio block as well. Runtime SGL allocation has always been the case
> for the legacy I/O path so this is nothing new.
>
> The preallocated small SGL depends on SG_CHAIN so if the ARCH doesn't
> support SG_CHAIN, use only runtime allocation for the SGL.
>
> Signed-off-by: Max Gurtovoy 
> Reviewed-by: Israel Rukshin 
> ---
>  drivers/block/virtio_blk.c | 37 ++---
>  1 file changed, 22 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 77e8468e8593..9a4c5d428b58 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -24,6 +24,12 @@
>  /* The maximum number of sg elements that fit into a virtqueue */
>  #define VIRTIO_BLK_MAX_SG_ELEMS 32768
>
> +#ifdef CONFIG_ARCH_NO_SG_CHAIN
> +#define VIRTIO_BLK_INLINE_SG_CNT   0
> +#else
> +#define VIRTIO_BLK_INLINE_SG_CNT   2
> +#endif
> +
>  static int virtblk_queue_count_set(const char *val,
> const struct kernel_param *kp)
>  {
> @@ -99,7 +105,7 @@ struct virtio_blk {
>  struct virtblk_req {
> struct virtio_blk_outhdr out_hdr;
> u8 status;
> -   struct scatterlist sg[];
> +   struct sg_table sg_table;
>  };
>
>  static inline blk_status_t virtblk_result(struct virtblk_req *vbr)
> @@ -188,6 +194,8 @@ static inline void virtblk_request_done(struct request 
> *req)
>  {
> struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
>
> +   sg_free_table_chained(>sg_table, VIRTIO_BLK_INLINE_SG_CNT);
> +
> if (req->rq_flags & RQF_SPECIAL_PAYLOAD) {
> kfree(page_address(req->special_vec.bv_page) +
>   req->special_vec.bv_offset);
> @@ -291,7 +299,15 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx 
> *hctx,
> return BLK_STS_RESOURCE;
> }
>
> -   num = blk_rq_map_sg(hctx->queue, req, vbr->sg);
> +   vbr->sg_table.sgl = (struct scatterlist *)(vbr + 1);
> +   err = sg_alloc_table_chained(>sg_table,
> +blk_rq_nr_phys_segments(req),
> +vbr->sg_table.sgl,
> +VIRTIO_BLK_INLINE_SG_CNT);
> +   if (err)
> +   return BLK_STS_RESOURCE;
> +
> +   num = blk_rq_map_sg(hctx->queue, req, vbr->sg_table.sgl);
> if (num) {
> if (rq_data_dir(req) == WRITE)
> vbr->out_hdr.type |= cpu_to_virtio32(vblk->vdev, 
> VIRTIO_BLK_T_OUT);
> @@ -300,7 +316,7 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx 
> *hctx,
> }
>
> spin_lock_irqsave(>vqs[qid].lock, flags);
> -   err = virtblk_add_req(vblk->vqs[qid].vq, vbr, vbr->sg, num);
> +   err = virtblk_add_req(vblk->vqs[qid].vq, vbr, vbr->sg_table.sgl, num);
> if (err) {
> virtqueue_kick(vblk->vqs[qid].vq);
> /* Don't stop the queue if -ENOMEM: we may have failed to
> @@ -309,6 +325,8 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx 
> *hctx,
> if (err == -ENOSPC)
> blk_mq_stop_hw_queue(hctx);
> spin_unlock_irqrestore(>vqs[qid].lock, flags);
> +   sg_free_table_chained(>sg_table,
> + VIRTIO_BLK_INLINE_SG_CNT);
> switch (err) {
> case -ENOSPC:
> return BLK_STS_DEV_RESOURCE;
> @@ -687,16 +705,6 @@ static const struct attribute_group 
> *virtblk_attr_groups[] = {
> NULL,
>  };
>
> -static int virtblk_init_request(struct blk_mq_tag_set *set, struct request 
> *rq,
> -   unsigned int hctx_idx, unsigned int numa_node)
> -{
> -   struct virtio_blk *vblk = set->driver_data;
> -   struct virtblk_req *vbr = blk_mq_rq_to_pdu(rq);
> -
> -   sg_init_table(vbr->sg, vblk->sg_elems);
> -   return 0;
> -}
> -
>  static int virtblk_map_queues(struct blk_mq_tag_set *set)
>  {
> struct virtio_blk *vblk = set->driver_data;
> @@ -709,7 +717,6 @@ static const struct blk_mq_ops virtio_mq_ops = {
> .queue_rq   = virtio_queue_rq,
> .commit_rqs = virtio_commit_rqs,
> .complete   = virtblk_request_done,
> -   .init_request   = virtblk_init_request,
> .map_queues = virtblk_map_queues,
>  };
>
> @@ 

Re: [PATCH v2 1/1] virtio-blk: add num_io_queues module parameter

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] gpio: virtio: Fix sparse warnings

[Michael S. Tsirkin]

On Tue, Aug 31, 2021 at 10:59:25AM +0530, Viresh Kumar wrote:
> Fix warnings reported by sparse, related to type mismatch between u16
> and __le16.
> 
> Reported-by: kernel test robot 
> Fixes: 3a29355a22c0 ("gpio: Add virtio-gpio driver")
> Signed-off-by: Viresh Kumar 

Acked-by: Michael S. Tsirkin 

I'm not sure which tree has the above commit - can this be squashed?

Also, the driver lacks a MAINTAINERS entry - we want at least
L:  virtualization@lists.linux-foundation.org
on all virtio drivers.


> ---
>  drivers/gpio/gpio-virtio.c   | 41 
>  include/uapi/linux/virtio_gpio.h | 10 
>  2 files changed, 25 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
> index d33eb237c0b9..d24f1c9264bc 100644
> --- a/drivers/gpio/gpio-virtio.c
> +++ b/drivers/gpio/gpio-virtio.c
> @@ -32,7 +32,6 @@ struct virtio_gpio {
>   struct virtio_device *vdev;
>   struct mutex lock; /* Protects virtqueue operation */
>   struct gpio_chip gc;
> - struct virtio_gpio_config config;
>   struct virtio_gpio_line *lines;
>   struct virtqueue *request_vq;
>  };
> @@ -57,7 +56,7 @@ static int _virtio_gpio_req(struct virtio_gpio *vgpio, u16 
> type, u16 gpio,
>  
>   req->type = cpu_to_le16(type);
>   req->gpio = cpu_to_le16(gpio);
> - req->value = txvalue;
> + req->value = cpu_to_le32(txvalue);
>  
>   sg_init_one(_sg, req, sizeof(*req));
>   sg_init_one(_sg, res, rxlen);
> @@ -233,19 +232,19 @@ static int virtio_gpio_alloc_vqs(struct virtio_gpio 
> *vgpio,
>   return 0;
>  }
>  
> -static const char **virtio_gpio_get_names(struct virtio_gpio *vgpio)
> +static const char **virtio_gpio_get_names(struct virtio_gpio *vgpio,
> +   u32 gpio_names_size, u16 ngpio)
>  {
> - struct virtio_gpio_config *config = >config;
>   struct virtio_gpio_response_get_names *res;
>   struct device *dev = >vdev->dev;
>   u8 *gpio_names, *str;
>   const char **names;
>   int i, ret, len;
>  
> - if (!config->gpio_names_size)
> + if (!gpio_names_size)
>   return NULL;
>  
> - len = sizeof(*res) + config->gpio_names_size;
> + len = sizeof(*res) + gpio_names_size;
>   res = devm_kzalloc(dev, len, GFP_KERNEL);
>   if (!res)
>   return NULL;
> @@ -258,18 +257,18 @@ static const char **virtio_gpio_get_names(struct 
> virtio_gpio *vgpio)
>   return NULL;
>   }
>  
> - names = devm_kcalloc(dev, config->ngpio, sizeof(*names), GFP_KERNEL);
> + names = devm_kcalloc(dev, ngpio, sizeof(*names), GFP_KERNEL);
>   if (!names)
>   return NULL;
>  
>   /* NULL terminate the string instead of checking it */
> - gpio_names[config->gpio_names_size - 1] = '\0';
> + gpio_names[gpio_names_size - 1] = '\0';
>  
> - for (i = 0, str = gpio_names; i < config->ngpio; i++) {
> + for (i = 0, str = gpio_names; i < ngpio; i++) {
>   names[i] = str;
>   str += strlen(str) + 1; /* zero-length strings are allowed */
>  
> - if (str > gpio_names + config->gpio_names_size) {
> + if (str > gpio_names + gpio_names_size) {
>   dev_err(dev, "gpio_names block is too short (%d)\n", i);
>   return NULL;
>   }
> @@ -280,31 +279,31 @@ static const char **virtio_gpio_get_names(struct 
> virtio_gpio *vgpio)
>  
>  static int virtio_gpio_probe(struct virtio_device *vdev)
>  {
> - struct virtio_gpio_config *config;
> + struct virtio_gpio_config config;
>   struct device *dev = >dev;
>   struct virtio_gpio *vgpio;
> + u32 gpio_names_size;
> + u16 ngpio;
>   int ret, i;
>  
>   vgpio = devm_kzalloc(dev, sizeof(*vgpio), GFP_KERNEL);
>   if (!vgpio)
>   return -ENOMEM;
>  
> - config = >config;
> -
>   /* Read configuration */
> - virtio_cread_bytes(vdev, 0, config, sizeof(*config));
> - config->gpio_names_size = le32_to_cpu(config->gpio_names_size);
> - config->ngpio = le16_to_cpu(config->ngpio);
> - if (!config->ngpio) {
> + virtio_cread_bytes(vdev, 0, , sizeof(config));
> + gpio_names_size = le32_to_cpu(config.gpio_names_size);
> + ngpio = le16_to_cpu(config.ngpio);
> + if (!ngpio) {
>   dev_err(dev, "Number of GPIOs can't be zero\n");
>   return -EINVAL;
>   }
>  
> - vgpio->lines = devm_kcalloc(dev, config->ngpio, sizeof(*vgpio->lines), 
> GFP_KERNEL);
> + vgpio->lines = devm_kcalloc(dev, ngpio, sizeof(*vgpio->lines), 
> GFP_KERNEL);
>   if (!vgpio->lines)
>   return -ENOMEM;
>  
> - for (i = 0; i < config->ngpio; i++) {
> + for (i = 0; i < ngpio; i++) {
>   mutex_init(>lines[i].lock);
>   init_completion(>lines[i].completion);
>   }
> @@ -319,7 +318,7 @@ static int virtio_gpio_probe(struct virtio_device *vdev)
>   

[PATCH] gpio: virtio: Add missing mailings lists in MAINTAINERS entry

[Viresh Kumar]

Add gpio and virtualization lists in the MAINTAINERS entry for Virtio
gpio driver.

Reported-by: "Michael S. Tsirkin" 
Signed-off-by: Viresh Kumar 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f632acd7d98c..da58964935d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19650,6 +19650,8 @@ F:  include/uapi/linux/virtio_fs.h
 VIRTIO GPIO DRIVER
 M: Enrico Weigelt, metux IT consult 
 M: Viresh Kumar 
+L: linux-g...@vger.kernel.org
+L: virtualization@lists.linux-foundation.org
 S: Maintained
 F: drivers/gpio/gpio-virtio.c
 F: include/uapi/linux/virtio_gpio.h
-- 
2.31.1.272.g89b43f80a514

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V7] gpio: Add virtio-gpio driver

[Michael S. Tsirkin]

On Mon, Aug 23, 2021 at 09:52:22AM +0200, Bartosz Golaszewski wrote:
> On Thu, Aug 19, 2021 at 6:30 AM Viresh Kumar  wrote:
> >
> > This patch adds a new driver for Virtio based GPIO devices.
> >
> > This allows a guest VM running Linux to access GPIO lines provided by
> > the host. It supports all basic operations, except interrupts for the
> > GPIO lines.
> >
> > Based on the initial work posted by:
> > "Enrico Weigelt, metux IT consult" .
> >
> > Reviewed-by: Linus Walleij 
> > Signed-off-by: Viresh Kumar 
> > ---
> > Bartosz,
> >
> > Can you please pick this up for 5.15, the specification is already merged 
> > now:
> >
> > https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-gpio.tex
> >
> > I will follow up with the IRQ stuff separately.
> >
> 
> Applied, thanks!
> 
> Bart

Um. didn't expect this to be applied yet, the driver is not
sparse clean, kernel build bot gave some other warnings too.

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] gpio: virtio: Fix sparse warnings

[Viresh Kumar]

On 31-08-21, 02:25, Michael S. Tsirkin wrote:
> On Tue, Aug 31, 2021 at 10:59:25AM +0530, Viresh Kumar wrote:
> > Fix warnings reported by sparse, related to type mismatch between u16
> > and __le16.
> > 
> > Reported-by: kernel test robot 
> > Fixes: 3a29355a22c0 ("gpio: Add virtio-gpio driver")
> > Signed-off-by: Viresh Kumar 
> 
> Acked-by: Michael S. Tsirkin 
> 
> I'm not sure which tree has the above commit - can this be squashed?

It has gone via the GPIO tree:

https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git/log/?h=gpio/for-next

I believe it can be squashed, Bartosz can confirm the same though.

> Also, the driver lacks a MAINTAINERS entry - we want at least
> L:  virtualization@lists.linux-foundation.org
> on all virtio drivers.

Sure, I will send a patch for that.

-- 
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization