Re: [Qemu-devel] Why got no response of vnc?

2017-08-26 Thread Philipp Hahn 
Hello,

Am 25.08.2017 um 08:31 schrieb Sam:
> I'm starting vm using:
> 
> kvm]$ sudo /usr/local/bin/qemu-system-x86_64 -m 256 -hda test.qcow2 -cdrom
>> CentOS-7-x86_64-DVD-1503-01.iso -boot d
>> VNC server running on '127.0.0.1:5900'
  ^
This a a *local* host socket,

> then I start vnc client in another PC to connect 10.253.23.24:11800 and
> 10.253.23.24:5900, I got time out, why?

to which you can't connect from any *other* host

$ man qemu-system-x86_64
...
> -vnc display[,option[,option[,...]]]

So try to add '-vnc 10.253.23.24:5900' to your command line to make Qemu
to listen on that IP address of your host you're running the VM on.

Philipp

Re: [Qemu-devel] [PATCH 1/2] migration: Reset rather than destroy main_thread_load_event

2017-08-26 Thread Stafford Horne 
On Fri, Aug 25, 2017 at 03:19:39PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> migration_incoming_state_destroy doesn't really destroy, it cleans up.
> After a loadvm it's called, but the loadvm command can be run twice,
> and so destroying an init-once mutex breaks on the second loadvm.
> 
> Reported-by: Stafford Horne 
> Signed-off-by: Dr. David Alan Gilbert 
> ---
>  migration/migration.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index c3fe0ed9ca..a625551ce5 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -167,7 +167,7 @@ void migration_incoming_state_destroy(void)
>  mis->from_src_file = NULL;
>  }
>  
> -qemu_event_destroy(>main_thread_load_event);
> +qemu_event_reset(>main_thread_load_event);
>  }
>  
>  static void migrate_generate_event(int new_state)

For what its worth:

Tested-by: Stafford Horne 

Thanks, I saw the mail from Peter as well, I agree it makes sense to not
call the parent method destroy.  But this works for me at the moment.

-Stafford

Re: [Qemu-devel] [RFC v2 2/8] monitor: allow monitor to create thread to poll

2017-08-26 Thread Marc-André Lureau 
Hi

On Fri, Aug 25, 2017 at 6:29 PM Dr. David Alan Gilbert 
wrote:

> * Marc-André Lureau (marcandre.lur...@gmail.com) wrote:
> > > In (2),  info cpus
> > > > shouldn't keep the BQL (my qapi-async series would probably help
> here)
> > >
> > > How does that work?
> > >
> > >
> > https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03626.html
> >
> > With the series, a command can be broken up in receive/start &
> > finish/reply. This allows to reenter the loop, potentially freeing the
> BQL,
> > and process other events. This allowed me to fix a screendump glitch bug
> (
> > http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03650.html).
> This
> > also open the door to concurrent QMP commands (if the client turns on the
> > capability option).
>
> Interesting.
> I can see how that would work well for commands that know they're long
> lived and do that work to split themselves into
> receive/start/finish/reply.  However I'm worried that it means that
> it's fragile in that if something accesses guest memory when they din't
> realise they were doing, or code that forgot it's taking the lock, then
> we've got a command that can occasionally block.  That's going to be a
> lot of analysis and design on each command and if we were to do it
> widely then we'd certainly miss some cases.  Having the monitors in
> spearate threads means you only have to worry about the commands
> you want to be lock-free.
>

Well the concurrency problems are essentially similar in both cases, but I
would argue that avoiding parallelism is easier to deal with. My approach
is also very conservative, only commands that are "async-free" are broken
up, so you mostly have to worry about those regarding concurrency. But with
a seperate thread, you have additional concerns, since you may run while
the BQL is taken somewhere else.

-- 
Marc-André Lureau

[Qemu-devel] [PATCH v19 2/2] virtio-crypto: Add conformance clauses

2017-08-26 Thread Longpeng(Mike) 
From: Gonglei 

Add the conformance targets and clauses for
virtio-crypto device.

Signed-off-by: Gonglei 
Signed-off-by: Longpeng(Mike) 
---
 conformance.tex | 29 +
 1 file changed, 29 insertions(+)

diff --git a/conformance.tex b/conformance.tex
index 7b7df32..266a22f 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -145,6 +145,21 @@ An SCSI host driver MUST conform to the following 
normative statements:
 \item \ref{drivernormative:Device Types / SCSI Host Device / Device Operation 
/ Device Operation: eventq}
 \end{itemize}
 
+\subsection{Crypto Driver Conformance}\label{sec:Conformance / Driver 
Conformance / Crypto Driver Conformance}
+
+A Crypto driver MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{drivernormative:Device Types / Crypto Device / Device configuration 
layout}
+\item \ref{drivernormative:Device Types / Crypto Device / Device 
Initialization}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / 
Control Virtqueue / Session operation / Session operation: create session}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / 
Control Virtqueue / Session operation / Session operation: destroy session}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / 
HASH Service operation}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / 
MAC Service operation}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / 
Symmetric algorithms Operation}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / 
AEAD Service operation}
+\end{itemize}
+
 \section{Device Conformance}\label{sec:Conformance / Device Conformance}
 
 A device MUST conform to the following normative statements:
@@ -265,6 +280,20 @@ An SCSI host device MUST conform to the following 
normative statements:
 \item \ref{devicenormative:Device Types / SCSI Host Device / Device Operation 
/ Device Operation: eventq}
 \end{itemize}
 
+\subsection{Crypto Device Conformance}\label{sec:Conformance / Device 
Conformance / Crypto Device Conformance}
+
+A Crypto device MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{devicenormative:Device Types / Crypto Device / Device configuration 
layout}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / 
Control Virtqueue / Session operation / Session operation: create session}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / 
Control Virtqueue / Session operation / Session operation: destroy session}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / 
HASH Service operation}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / 
MAC Service operation}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / 
Symmetric algorithms Operation}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / 
AEAD Service operation}
+\end{itemize}
+
 \section{Legacy Interface: Transitional Device and
 Transitional Driver Conformance}\label{sec:Conformance / Legacy
 Interface: Transitional Device and 
-- 
2.7.4

[Qemu-devel] [PATCH v19 1/2] virtio-crypto: Add virtio crypto device specification

2017-08-26 Thread Longpeng(Mike) 
From: Gonglei 

The virtio crypto device is a virtual crypto device (ie. hardware
crypto accelerator card). Currently, the virtio crypto device provides
the following crypto services: CIPHER, MAC, HASH, and AEAD.

In this patch, CIPHER, MAC, HASH, AEAD services are introduced.

VIRTIO-153

Signed-off-by: Gonglei 
Signed-off-by: Longpeng(Mike) 
---
 acknowledgements.tex |3 +
 content.tex  |2 +
 virtio-crypto.tex| 1479 ++
 3 files changed, 1484 insertions(+)
 create mode 100644 virtio-crypto.tex

diff --git a/acknowledgements.tex b/acknowledgements.tex
index 6c86d12..c4b6844 100644
--- a/acknowledgements.tex
+++ b/acknowledgements.tex
@@ -26,6 +26,8 @@ Sasha Levin,  Oracle  \newline
 Sergey Tverdyshev, Thales e-Security   \newline
 Stefan Hajnoczi,   Red Hat \newline
 Tom Lyon,  Samya Systems, Inc. \newline
+Lei Gong,  Huawei  \newline
+Peng Long, Huawei  \newline
 \end{oasistitlesection}
 
 The following non-members have provided valuable feedback on this
@@ -43,4 +45,5 @@ Laura Novich, Red Hat \newline
 Patrick Durusau,   Technical Advisory Board, OASIS \newline
 Thomas Huth,   IBM \newline
 Yan Vugenfirer, Red Hat / Daynix   \newline
+Halil Pasic,   IBM \newline
 \end{oasistitlesection}
diff --git a/content.tex b/content.tex
index d989d98..7710f8c 100644
--- a/content.tex
+++ b/content.tex
@@ -5641,6 +5641,8 @@ descriptor for the \field{sense_len}, \field{residual},
 \field{status_qualifier}, \field{status}, \field{response} and
 \field{sense} fields.
 
+\input{virtio-crypto.tex}
+
 \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
 
 Currently there are three device-independent feature bits defined:
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
new file mode 100644
index 000..1e75cbc
--- /dev/null
+++ b/virtio-crypto.tex
@@ -0,0 +1,1479 @@
+\section{Crypto Device}\label{sec:Device Types / Crypto Device}
+
+The virtio crypto device is a virtual cryptography device as well as a
+virtual cryptographic accelerator. The virtio crypto device provides the
+following crypto services: CIPHER, MAC, HASH, and AEAD. Virtio crypto
+devices have a single control queue and at least one data queue. Crypto
+operation requests are placed into a data queue, and serviced by the
+device. Some crypto operation requests are only valid in the context of a
+session. The role of the control queue is facilitating control operation
+requests. Sessions management is realized with control operation
+requests.
+
+\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
+
+20
+
+\subsection{Virtqueues}\label{sec:Device Types / Crypto Device / Virtqueues}
+
+\begin{description}
+\item[0] dataq1
+\item[\ldots]
+\item[N-1] dataqN
+\item[N] controlq
+\end{description}
+
+N is set by \field{max_dataqueues}.
+
+\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature 
bits}
+
+\begin{description}
+\item VIRTIO_CRYPTO_F_MUX_MODE (0) multiplexing mode is available.
+\item VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE (1) stateless mode is available 
for CIPHER service.
+\item VIRTIO_CRYPTO_F_HASH_STATELESS_MODE (2) stateless mode is available for 
HASH service.
+\item VIRTIO_CRYPTO_F_MAC_STATELESS_MODE (3) stateless mode is available for 
MAC service.
+\item VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE (4) stateless mode is available for 
AEAD service.
+\end{description}
+
+\subsubsection{Feature bit requirements}\label{sec:Device Types / Crypto 
Device / Feature bits}
+
+Some crypto feature bits require other crypto feature bits
+(see \ref{drivernormative:Basic Facilities of a Virtio Device / Feature Bits}):
+
+\begin{description}
+\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.
+\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.
+\item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.
+\item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.
+\end{description}
+
+\subsection{Supported crypto services}\label{sec:Device Types / Crypto Device 
/ Supported crypto services}
+
+The following crypto services are defined:
+
+\begin{lstlisting}
+/* CIPHER service */
+#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
+/* HASH service */
+#define VIRTIO_CRYPTO_SERVICE_HASH   1
+/* MAC (Message Authentication Codes) service */
+#define VIRTIO_CRYPTO_SERVICE_MAC2
+/* AEAD (Authenticated Encryption with Associated Data) service */
+#define VIRTIO_CRYPTO_SERVICE_AEAD   3
+\end{lstlisting}
+
+The above constants designate bits used to indicate the which of crypto 
services are
+offered by the device as described in, see \ref{sec:Device Types / Crypto 
Device / Device configuration layout}.
+
+\subsubsection{CIPHER services}\label{sec:Device Types / Crypto Device / 
Supported crypto services / CIPHER services}
+
+The following CIPHER

[Qemu-devel] [PATCH v19 0/2] virtio-crypto: virtio crypto device specification

2017-08-26 Thread Longpeng(Mike) 
Hi guys,

I'll work on the virtio-crypto spec with Gonglei together, Because He is
so busy on the inner production project.

---
v19 -> v18:
 - fix some typos and grammar fixes [Stefan, Halil]
 - rename VIRTIO_CRYPTO_F_STATELESS_MODE to VIRTIO_CRYPTO_F_MUX_MODE
 - describe the VIRTIO_CRYPTO_STATUS in detial. [Halil]
 - refactor and redescribe the controlq/dataq request's format
   of mux mode. [Halil]
 - other small fixes. [Halil]

v18 -> v17:
 - fix many English grammar problems suggested by Stefan, Thanks a lot!

v17 -> v16:
 - Some grammar fixes [Stefan, Halil, Michael]
 - add a section named "Supported crypto services" in order to explain bit
   numbers and valuse clearly. [Halil, Cornelia]
 - avoid word reptition [Halil]
 - rename non-session mode to stateless mode [Halil]
 - change descriptions for all elements in struct virtio_crypto_config [Halil]
 - add Halil as a reviewer in the ackonwledgement part, thanks for his work.
 - other fixes here and there.

Changes since v15:
 - use feature bits for non-session mode in order to keep compatibility with
   pre-existing code. [Halil & Michael]
 - introduce VIRTIO_CRYPTO_F_ NON_SESSION_MODE feature bit to control all other
   non-session mode feature bits.
 - fix some typos. [Stefan]
 - introduce struct virtio_crypto_op_data_req_mux to support both session
   and non-session based crypto operations and keep compatibility with
   pre-existing code.

Changes since v14:
 - drop VIRTIO_CRYPTO_S_STARTED status [Halil & Cornelia]
 - correct a sentence about dataqueue and controlq in the first paragraph. 
[Halil]
 - change a MAY to MUST about max_dataqueues. [Halil]
 - add non-session mode support
   a) add four features for different crypto services to identify wheather 
support session mode.
   b) rewrite some

For pervious versions of virtio crypto spec, Pls see:

[v18]:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg444897.html

[v14]:
https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg02212.html

[v13]:
https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg07348.html

For more information, please see:
 http://qemu-project.org/Features/VirtioCrypto

---
Gonglei (2):
  virtio-crypto: Add virtio crypto device specification
  virtio-crypto: Add conformance clauses

 acknowledgements.tex |3 +
 conformance.tex  |   29 +
 content.tex  |2 +
 virtio-crypto.tex| 1470 ++
 4 files changed, 1504 insertions(+)
 create mode 100644 virtio-crypto.tex

-- 
2.7.4

Re: [Qemu-devel] [RFC v2 3/8] char-io: fix possible risk on IOWatchPoll

2017-08-26 Thread Fam Zheng 
s/risk/race/ for $subject and the whole patch?

Fam

On Wed, 08/23 14:51, Peter Xu wrote:
> This is not a problem if we are only having one single loop thread like
> before.  However, after per-monitor thread is introduced, this is not
> true any more, and the risk can happen.
> 
> The risk can be triggered with "make check -j8" sometimes:
> 
>   qemu-system-x86_64: /root/git/qemu/chardev/char-io.c:91:
>   io_watch_poll_finalize: Assertion `iwp->src == NULL' failed.
> 
> This patch keeps the reference for the watch object when creating in
> io_add_watch_poll(), so that the object will never be released in the
> context main loop, especially when the context loop is running in
> another standalone thread.  Meanwhile, when we want to remove the watch
> object, we always first detach the watch object from its owner context,
> then we continue with the cleanup.
> 
> Without this patch, calling io_remove_watch_poll() in main loop thread
> is not thread-safe, since the other per-monitor thread may be modifying
> the watch object at the same time.
> 
> Signed-off-by: Peter Xu 
> ---
>  chardev/char-io.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/chardev/char-io.c b/chardev/char-io.c
> index f810524..5c52c40 100644
> --- a/chardev/char-io.c
> +++ b/chardev/char-io.c
> @@ -122,7 +122,6 @@ GSource *io_add_watch_poll(Chardev *chr,
>  g_free(name);
>  
>  g_source_attach(>parent, context);
> -g_source_unref(>parent);
>  return (GSource *)iwp;
>  }
>  
> @@ -131,12 +130,24 @@ static void io_remove_watch_poll(GSource *source)
>  IOWatchPoll *iwp;
>  
>  iwp = io_watch_poll_from_source(source);
> +
> +/*
> + * Here the order of destruction really matters.  We need to first
> + * detach the IOWatchPoll object from the context (which may still
> + * be running in another loop thread), only after that could we
> + * continue to operate on iwp->src, or there may be risk condition
> + * between current thread and the context loop thread.
> + *
> + * Let's blame the glib bug mentioned in commit 2b3167 (again) for
> + * this extra complexity.
> + */
> +g_source_destroy(>parent);
>  if (iwp->src) {
>  g_source_destroy(iwp->src);
>  g_source_unref(iwp->src);
>  iwp->src = NULL;
>  }
> -g_source_destroy(>parent);
> +g_source_unref(>parent);
>  }
>  
>  void remove_fd_in_watch(Chardev *chr)
> -- 
> 2.7.4
>