Re: [Qemu-devel] [PATCH 16/18] nbd: Support NBD_CMD_CLOSE

On 10 Apr 2016, at 00:12, Eric Blake wrote: > Qemu clients _already_ do the safe actions of waiting for all inflight > requests to complete, then sending one final NBD_CMD_FLUSH, before > attempting to send NBD_CMD_DISC. If I knew how to make qemu guarantee > that the

Re: [Qemu-devel] [RFC PATCH 18/18] nbd: Implement NBD_CMD_WRITE_ZEROES on client

On 10 Apr 2016, at 00:17, Eric Blake wrote: > No, the code is correct. In both functions, the logic is that if the > lower-level knows that the server respects FUA, then it clears the flag > before returning (flags is passed by reference, not value). Then at > this higher

Re: [Qemu-devel] [PATCH] Change return type of functions that are named *_exit or *_exitfn in hw/ from int to void.

Hi, > It's usually not a good idea to have one patch which touches > multiple completely different devices or subsystems. Shall I send multiple patches with subject [PATCH v2 1/3], [PATCH v2 2/3], [PATCH v2 3/3] ? Regards, Nutan. On Thu, Mar 24, 2016 at 11:49 PM, Peter Maydell

Re: [Qemu-devel] [Nbd] NBD_CMD_DISC

[adding qemu list and Dan into the mix] On 04/09/2016 05:02 PM, Alex Bligh wrote: > > On 9 Apr 2016, at 22:12, Eric Blake wrote: > >>> How would the client know that? I'm using Go's TLS library, and there is >>> no way (as far as I can tell) to ensure that. >> >> Likewise -

Re: [Qemu-devel] [RFC PATCH 18/18] nbd: Implement NBD_CMD_WRITE_ZEROES on client

On 04/09/2016 04:57 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake wrote: > >> RFC because there is still discussion on the NBD list about >> adding an NBD_OPT_ to let the client suggest server defaults >> related to scanning for zeroes during NBD_CMD_WRITE,

Re: [Qemu-devel] [PATCH 16/18] nbd: Support NBD_CMD_CLOSE

On 04/09/2016 04:50 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake wrote: > >> NBD_CMD_DISC is annoying: the server is not required to reply, >> so the client has no choice but to disconnect once it has sent >> the message; but depending on timing, the server

Re: [Qemu-devel] [PATCHv6] Improve documentation for TLS

On 04/09/2016 06:06 AM, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I believe > and as

Re: [Qemu-devel] [RFC PATCH v2 1/3] target-arm: Use Neon for zero checking

On 04/07/2016 02:58 AM, vija...@caviumnetworks.com wrote: +#elif defined __aarch64__ +#include "arm_neon.h" A better test is __NEON__, which asserts that neon is available at compile time (which will be true basically always for aarch64), and then you don't need a runime test for neon. You

Re: [Qemu-devel] [PATCH v2 2/1 for-2.6] nbd: Don't kill server when client requests unknown option

Adding qemu-stable; this fix needs to be backported to 2.5.x stable series (in the file ./nbd.c at the time), if we want to be able to allow a 2.7 client to connect to a 2.5 server. On 04/06/2016 04:48 PM, Eric Blake wrote: > nbd-server.c currently fails to handle unsupported options properly. >

Re: [Qemu-devel] [PATCH 14/18] nbd: Implement NBD_OPT_GO on client

On 04/09/2016 04:47 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake wrote: > >> NBD_OPT_EXPORT_NAME is lousy: it doesn't have any sane error >> reporting. Upstream NBD recently added NBD_OPT_GO as the > > ... as an experimental option for now, but hopefully

Re: [Qemu-devel] [PATCH 13/18] nbd: Support shorter handshake

On 04/09/2016 04:42 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake wrote: > >> The NBD Protocol allows the server and client to mutually agree >> on a shorter handshake (omit the 124 bytes of reserved 0), via >> the server advertising NBD_FLAG_NO_ZEROES and the

Re: [Qemu-devel] [PATCH 12/18] nbd: Less allocation during NBD_OPT_LIST

On 04/09/2016 04:41 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake wrote: > >> Since we know that the maximum name we are willing to accept >> is small enough to stack-allocate, rework the iteration over >> NBD_OPT_LIST responses to reuse a stack buffer rather

Re: [Qemu-devel] [PATCH 06/18] nbd: Avoid magic number for NBD max name size

On 04/09/2016 04:35 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake wrote: > >> Declare a constant and use that when determining if an export >> name fits within the constraints we are willing to support. >> >> Signed-off-by: Eric Blake >>

[Qemu-devel] [PATCH for-2.7 3/4] target-i386: Set constant model_id for qemu63/qemu32/athlon

Newer PC machines don't set hw_version, and older machines set model-id on compat_props explicitly, so we don't need the x86_cpudef_setup() code that sets model_id using qemu_hw_version() anymore. Signed-off-by: Eduardo Habkost --- target-i386/cpu.c | 23

[Qemu-devel] [PATCH for-2.7 0/4] cpu: Finally remove cpudef_init()

The only reason cpudef_init() still exists is the qemu_hw_version()-based model_id hack at x86_cpudef_setup(). Move the model_id hack to machine compat_props so we can make the model_id field constant at the CPU model table, and then remove cpudef_init() completely. Eduardo Habkost (4): osdep:

[Qemu-devel] [PATCH for-2.7 4/4] cpu: Eliminate cpudef_init(), cpudef_setup()

x86_cpudef_init() doesn't do anything anymore, cpudef_init(), cpudef_setup(), and x86_cpudef_init() can be finally removed. Signed-off-by: Eduardo Habkost --- arch_init.c| 7 --- bsd-user/main.c| 3 --- include/sysemu/arch_init.h | 1 -

[Qemu-devel] [PATCH for-2.7 2/4] pc: Set CPU model-id on compat_props for pc <= 2.4

Instead of relying on x86_cpudef_setup() calling qemu_hw_version(), just make old machines set model-id explicitly on compat_props for qemu64, qemu32, and athlon. This will allow us to eliminate x86_cpudef_setup() later. Signed-off-by: Eduardo Habkost --- hw/i386/pc_piix.c

[Qemu-devel] [PATCH for-2.7 1/4] osdep: Move default qemu_hw_version() value to a macro

The macro will be used by code that will stop calling qemu_hw_version() at runtime and just need a constant value. Signed-off-by: Eduardo Habkost --- include/qemu/osdep.h | 9 + util/osdep.c | 9 + 2 files changed, 10 insertions(+), 8 deletions(-)

[Qemu-devel] [Bug 1568356] [NEW] ERROR:ui/sdl2-2d.c:120:sdl2_2d_switch:

Public bug reported: when display sdl is selected in display switch resolution qemu exit with a core dump with this message ERROR:ui/sdl2-2d.c:120:sdl2_2d_switch: code should not be reached My Machine is a Cyrus+ PowerPc P5020 4gb ram Radeon 6570 2Gb This issue affected PowerMac G5 quad too

Re: [Qemu-devel] [PATCH v2] tpm: Fix write to file descriptor function

On 04/05/2016 08:21 PM, Stefan Berger wrote: Fix a bug introduced in commit 46f296c while moving send_all to the tpm_passthrough code. Fix the name of the variable used in the loop. Would someone please pick up this fix? Signed-off-by: Stefan Berger ---

[Qemu-devel] [PATCH RFC v2] IOMMU: Add Support to VFIO devices with vIOMMU present

From: "Aviv Ben-David" Date: Tue, 23 Feb 2016 00:24:54 +0200 Subject: [PATCH] IOMMU: Add Support to VFIO devices with vIOMMU present * Fix bug that prevent qemu from starting up with vIOMMU and VFIO device are present. * Advertize Cache Mode capability in iommu cap register.

Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation

On Fri, Apr 08, 2016 at 06:31:55PM +0200, Markus Armbruster wrote: > Interface and doc review only. Sorry for the delay, I was on vacation. > > "Michael S. Tsirkin" writes: > > > This requires that all -fw_cfg command line users use names of the form > > What's "this"? Do

Re: [Qemu-devel] best way to implement emulation of AArch64 tagged addresses

On 04/08/2016 05:29 PM, Thomas Hanson wrote: Looking at tcg_out_tlb_load(): If I'm reading the pseudo-assembler of the function names correctly, it looks like in the i386 code we're already masking the address being checked: tgen_arithi(s, ARITH_AND + trexw, r1, TARGET_PAGE_MASK | (aligned

[Qemu-devel] [RFC 5/6] contrib: add libvhost-user

From: Marc-André Lureau Add a library to help implementing vhost-user backend (or slave). Dealing with vhost-user as an application developper isn't so easy: you have all the trouble with any protocol: validation, unix ancillary data, shared memory, eventfd,

Re: [Qemu-devel] [PATCH] qdev property: cleanup

On 04/08/2016 07:17 PM, Markus Armbruster wrote: - * Static properties access data in a struct. The actual type of the - * property and the field depends on the property type. + * Static properties access data in a struct. The actual type of ObjectProperty + * and the struct field depends on

[Qemu-devel] [RFC 6/6] test/vubr: use contrib/libvhost-user

From: Marc-André Lureau Use the libvhost-user library. This ended up being a rather large patch that cannot be easily splitted, due to massive code move and API changes. Signed-off-by: Marc-André Lureau --- tests/Makefile|

[Qemu-devel] [RFC 3/6] vubr: indicate peer disconnected

From: Marc-André Lureau Signed-off-by: Marc-André Lureau --- tests/vhost-user-bridge.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c index b9bf018..b7bb79a 100644 ---

[Qemu-devel] [RFC 4/6] vubr: do not accept more than one connection

From: Marc-André Lureau Signed-off-by: Marc-André Lureau --- tests/vhost-user-bridge.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c index b7bb79a..c21cd79 100644 ---

[Qemu-devel] [RFC 2/6] vubr: remove unnecessary dispatcher_remove

From: Marc-André Lureau The call fd is not watched Signed-off-by: Marc-André Lureau --- tests/vhost-user-bridge.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c index

[Qemu-devel] [RFC 0/6] Start a contrib/libvhost-user

From: Marc-André Lureau Hi vhost-user & virtio are not so simple and evolve regularly. There isn't a reference code that would help you get started either. And backends duplicate most of the effort. Furthermore, due to usage of ancillary data, shared memory,

[Qemu-devel] [RFC 1/6] vubr: remove false comment

From: Marc-André Lureau dispatcher_remove() is in use. Signed-off-by: Marc-André Lureau --- tests/vhost-user-bridge.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c index

[Qemu-devel] [PATCH 2/2] specs/vhost-user: spelling fix

From: Marc-André Lureau Signed-off-by: Marc-André Lureau --- docs/specs/vhost-user.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt index 4778241..777c49c

[Qemu-devel] [PATCH 1/2] specs/vhost-user: improve VHOST_SET_VRING_NUM documentation

From: Marc-André Lureau "number of vrings" doesn't help me understand the purpose of this message. My understanding is that it is rather the size of the queue (in modern terms). Signed-off-by: Marc-André Lureau ---

Re: [Qemu-devel] [PATCH v4 3/5] megasas: bugfix

On 04/08/2016 03:16 PM, Markus Armbruster wrote: Please use a more descriptive title. Suggest "megasas: Fix Cao jin writes: msi_init returns non-zero value on both failure and success This is a sentence, should end with a period. Bug's impact? Here's my

Re: [Qemu-devel] [PATCH v4 5/5] Add param Error ** for msi_init()

On 04/09/2016 08:19 PM, Cao jin wrote: Hi Several questions on this topic: 1. How to confirm whether a device model has non-MSI variant? AFAICT, it is these who have msi property. 2. For those have non-MSI variant devices(have msi property), as I see in the code, they all have it on by

Re: [Qemu-devel] [PATCH for-2.6] target-sparc: fix ldstub sign-extension bug

On Sat, Apr 9, 2016 at 1:43 PM, Mark Cave-Ayland wrote: > ldstub [addr], reg incorrectly reads a signed byte from memory which causes > problems in the 32-bit Solaris mutex code. Here the byte value being read is > 0xff which is incorrectly sign-extended to

Re: [Qemu-devel] [PATCH v4 5/5] Add param Error ** for msi_init()

Hi On 04/08/2016 04:44 PM, Markus Armbruster wrote: diff --git a/hw/ide/ich.c b/hw/ide/ich.c index 0a13334..db4fdb5 100644 --- a/hw/ide/ich.c +++ b/hw/ide/ich.c @@ -146,7 +146,7 @@ static void pci_ich9_ahci_realize(PCIDevice *dev, Error **errp) /* Although the AHCI 1.3 specification

Re: [Qemu-devel] [RFC PATCH 18/18] nbd: Implement NBD_CMD_WRITE_ZEROES on client

On Sat, Apr 09, 2016 at 11:57:57AM +0100, Alex Bligh wrote: > > On 8 Apr 2016, at 23:05, Eric Blake wrote: > > > RFC because there is still discussion on the NBD list about > > adding an NBD_OPT_ to let the client suggest server defaults > > related to scanning for zeroes

[Qemu-devel] [PATCHv6] Improve documentation for TLS

* Call out TLS into a separate section * Add details of the TLS protocol itself * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can be initiated from either side (as required by the TLS standard I believe and as actually works in practice) * Clarify what is a

Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS

Wouter, On 9 Apr 2016, at 12:38, Wouter Verhelst wrote: > On Sat, Apr 09, 2016 at 12:21:03PM +0100, Alex Bligh wrote: >> An alternative route would be to delete OPTIONALTLS, and make some of >> the MUST requirements in SELECTIVETLS say "MUST xyz unless there are >> no TLS-only

[Qemu-devel] [PATCH for-2.6] target-sparc: fix ldstub sign-extension bug

ldstub [addr], reg incorrectly reads a signed byte from memory which causes problems in the 32-bit Solaris mutex code. Here the byte value being read is 0xff which is incorrectly sign-extended to 0x before being written back to the target register causing lock detection to behave

Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS

On Sat, Apr 09, 2016 at 12:21:03PM +0100, Alex Bligh wrote: > An alternative route would be to delete OPTIONALTLS, and make some of > the MUST requirements in SELECTIVETLS say "MUST xyz unless there are > no TLS-only exports". However, this makes it rather harder to read, > so I described that

Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS

Wouter, On 9 Apr 2016, at 11:38, Wouter Verhelst wrote: >> >> As per previous message, because SELECTIVETLS requires INFO, >> but OPTIONALTLS doesn't. > > Um. So you're suggesting that if a client sends INFO, we're suddenly in > a whole different mode of operation? > > That

Re: [Qemu-devel] [RFC PATCH 18/18] nbd: Implement NBD_CMD_WRITE_ZEROES on client

On 8 Apr 2016, at 23:05, Eric Blake wrote: > RFC because there is still discussion on the NBD list about > adding an NBD_OPT_ to let the client suggest server defaults > related to scanning for zeroes during NBD_CMD_WRITE, which may > tweak this patch. > > Upstream NBD

Re: [Qemu-devel] [RFC PATCH 17/18] nbd: Implement NBD_CMD_WRITE_ZEROES on server

On 8 Apr 2016, at 23:05, Eric Blake wrote: > RFC because there is still discussion on the NBD list about > adding an NBD_OPT_ to let the client suggest server defaults > related to scanning for zeroes during NBD_CMD_WRITE, which may > tweak this patch. > > Upstream NBD

Re: [Qemu-devel] [PATCH 16/18] nbd: Support NBD_CMD_CLOSE

On 8 Apr 2016, at 23:05, Eric Blake wrote: > NBD_CMD_DISC is annoying: the server is not required to reply, > so the client has no choice but to disconnect once it has sent > the message; but depending on timing, the server can see the > disconnect prior to reading the

Re: [Qemu-devel] [PATCH 15/18] nbd: Implement NBD_OPT_GO on server

On 8 Apr 2016, at 23:05, Eric Blake wrote: > NBD_OPT_EXPORT_NAME is lousy: it requires us to close the connection > rather than report an error. Upstream NBD recently added NBD_OPT_GO > as the improved version of the option that does what we want, along > with NBD_OPT_INFO

Re: [Qemu-devel] [PATCH 14/18] nbd: Implement NBD_OPT_GO on client

On 8 Apr 2016, at 23:05, Eric Blake wrote: > NBD_OPT_EXPORT_NAME is lousy: it doesn't have any sane error > reporting. Upstream NBD recently added NBD_OPT_GO as the ... as an experimental option for now, but hopefully this should move it out the experimental section.

Re: [Qemu-devel] [PATCH 13/18] nbd: Support shorter handshake

On 8 Apr 2016, at 23:05, Eric Blake wrote: > The NBD Protocol allows the server and client to mutually agree > on a shorter handshake (omit the 124 bytes of reserved 0), via > the server advertising NBD_FLAG_NO_ZEROES and the client > acknowledging with NBD_FLAG_C_NO_ZEROES

Re: [Qemu-devel] [PATCH 12/18] nbd: Less allocation during NBD_OPT_LIST

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Since we know that the maximum name we are willing to accept > is small enough to stack-allocate, rework the iteration over > NBD_OPT_LIST responses to reuse a stack buffer rather than > allocating every time. Furthermore, we

Re: [Qemu-devel] [PATCH 10/18] nbd: Share common option-sending code in client

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Rather than open-coding each option request, it's easier to > have common helper functions do the work. That in turn requires > having convenient packed types for handling option requests > and replies. > > Signed-off-by: Eric

Re: [Qemu-devel] [PATCH 11/18] nbd: Let client skip portions of server reply

On 8 Apr 2016, at 23:05, Eric Blake wrote: > The server has a nice helper function nbd_negotiate_drop_sync() > which lets it easily ignore fluff from the client (such as the > payload to an unknown option request). We can't quite make it > common, since it depends on

Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS

On Sat, Apr 09, 2016 at 11:26:23AM +0100, Alex Bligh wrote: > > On 9 Apr 2016, at 11:11, Wouter Verhelst wrote: > > Since you say zero here, how is it different from OPTIONALTLS? > > > > If "not at all", just drop optional. > > As per previous message, because SELECTIVETLS

Re: [Qemu-devel] [PATCH 09/18] nbd: Share common reply-sending code in server

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Rather than open-coding NBD_REP_SERVER, reuse the code we > already have by adding a length parameter. The code gets > longer because of added comments, but the refactoring will > make adding NBD_OPT_GO in a later patch easier. >

Re: [Qemu-devel] [PATCH 08/18] nbd: Limit nbdflags to 16 bits

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Rather than asserting that nbdflags is within range, just give > it the correct type to begin with :) nbdflags corresponds to > the per-export portion of NBD Protocol "transmission flags", which > is 16 bits in response to

Re: [Qemu-devel] [PATCH 07/18] nbd: Treat flags vs. command type as separate fields

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Current upstream NBD documents that requests have a 16-bit flags, > followed by a 16-bit type integer; although older versions mentioned > only a 32-bit field with masking to find flags. Since the protocol > is in network order

Re: [Qemu-devel] [PATCH 06/18] nbd: Avoid magic number for NBD max name size

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Declare a constant and use that when determining if an export > name fits within the constraints we are willing to support. > > Signed-off-by: Eric Blake > --- > include/block/nbd.h | 2 ++ > nbd/client.c

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On Sat, Apr 09, 2016 at 11:04:09AM +0100, Alex Bligh wrote: [...] > > [...] > >> +The server MUST NOT send `NBD_REP_ERR_TLS_REQD` in reply to > >> +any command if TLS has already been neogitated. The server > > > > negotiated > > I'd make sure you're looking at the latest version as Eagle Eyed

Re: [Qemu-devel] [PATCH 05/18] nbd: Reject unknown request flags

On 8 Apr 2016, at 23:05, Eric Blake wrote: > The NBD protocol says that clients should not send a command flag > that has not been negotiated (whether by the client requesting an > option during a handshake, or because we advertise support for the > flag in response to

Re: [Qemu-devel] [PATCH 04/18] nbd: Detect servers that send unexpected error values

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Add some debugging to flag servers that are not compliant to > the NBD protocol. > > Signed-off-by: Eric Blake Reviewed-by: Alex Bligh > --- > nbd/client.c | 4 +++- > 1 file changed, 3

Re: [Qemu-devel] [PATCH 03/18] nbd: More debug typo fixes, use correct formats

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Clean up some debug message oddities missed earlier; this includes > both typos, and recognizing that %d is not necessarily compatible > with uint32_t. > > Signed-off-by: Eric Blake Reviewed-by: Alex Bligh

Re: [Qemu-devel] [PATCH 02/18] nbd: Don't fail handshake on NBD_OPT_LIST descriptions

On 8 Apr 2016, at 23:05, Eric Blake wrote: > The NBD Protocol states that NBD_REP_SERVER may set > 'length > sizeof(namelen) + namelen'; in which case the rest > of the packet is a UTF-8 description of the export. While we > don't know of any NBD servers that send this

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On Sat, Apr 09, 2016 at 11:05:16AM +0100, Alex Bligh wrote: > > On 9 Apr 2016, at 10:50, Wouter Verhelst wrote: > > > So if I want to swap to qemu-nbd, I cannot also have encrypted > > connections to the same server. Got it. > > AFAIK qemu-nbd only supports a single export so

Re: [Qemu-devel] [PATCH 01/18] nbd: Don't kill server on client that doesn't request TLS

On 8 Apr 2016, at 23:05, Eric Blake wrote: > Upstream NBD is documenting that servers MAY choose to operate > in a conditional mode, where it is up to the client whether to > use TLS. For qemu's case, we want to always be in FORCEDTLS > mode, because of the risk of

Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS

On 9 Apr 2016, at 11:11, Wouter Verhelst wrote: > Since you say zero here, how is it different from OPTIONALTLS? > > If "not at all", just drop optional. As per previous message, because SELECTIVETLS requires INFO, but OPTIONALTLS doesn't. > I'm not *that* well versed in the

Re: [Qemu-devel] [Nbd] [RFC PATCH 00/18] NBD protocol additions

On Fri, Apr 08, 2016 at 04:05:40PM -0600, Eric Blake wrote: > This series is for qemu 2.7, and will probably need some rework > especially since some of it is trying to implement features > that are still marked experimental in upstream NBD. > > Included are some interoperability bug fixes, code

Re: [Qemu-devel] [Nbd] [PATCHv3] Improve documentation for TLS

On Thu, Apr 07, 2016 at 07:32:47PM +0100, Alex Bligh wrote: [...] > +### Server-side requirements > + > +There are four modes of operation for a server. The > +server MUST support one of these modes. > + > +* The server operates entirely without TLS ('NOTLS'); OR > + > +* The server makes TLS

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On 9 Apr 2016, at 10:55, Wouter Verhelst wrote: > > Yes. > >> That way, a client can send ANY option to learn if TLS is required (even >> an option that the server does not recognize); where NBD_OPT_INFO and >> NBD_OPT_LIST are probably the two most useful options, but where ANY

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On 9 Apr 2016, at 10:50, Wouter Verhelst wrote: > So if I want to swap to qemu-nbd, I cannot also have encrypted > connections to the same server. Got it. AFAIK qemu-nbd only supports a single export so this isn't really an issue. -- Alex Bligh

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On 9 Apr 2016, at 10:36, Wouter Verhelst wrote: >> +These modes of operations are described in detail below. >> + >> + NOTLS mode >> + >> +If the server receives `NBD_OPT_STARTTLS` it MUST respond with >> +`NBD_REP_ERR_UNSUPP`. The server MUST NOT respond to any > > No. UNSUP

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On Thu, Apr 07, 2016 at 08:31:23AM -0600, Eric Blake wrote: > > +The FORCEDTLS mode of operation has an implementation problem in > > +that the client MAY legally simply send a `NBD_OPT_EXPORT_NAME` > > +to enter transmission mode without previously sending any options. > > +Therefore, if a server

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On Thu, Apr 07, 2016 at 02:56:48PM +0100, Daniel P. Berrange wrote: > I don't really agree that there's a use case of mixing > tls & non-tls exports in the same server. There is: swap-on-NBD and TLS do not mix. Without special handling, swapping to the network is prone to deadlocks, because the

Re: [Qemu-devel] [RFC PATCH 17/18] nbd: Implement NBD_CMD_WRITE_ZEROES on server

On Fri, Apr 08, 2016 at 04:05:57PM -0600, Eric Blake wrote: > RFC because there is still discussion on the NBD list about > adding an NBD_OPT_ to let the client suggest server defaults > related to scanning for zeroes during NBD_CMD_WRITE, which may > tweak this patch. > > Upstream NBD protocol

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

On Thu, Apr 07, 2016 at 12:35:59PM +0100, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I

Re: [Qemu-devel] [PATCH] correct comment of MemoryHotplugState

ping? On 03/16/2016 04:00 AM, Eduardo Habkost wrote: On Mon, Mar 14, 2016 at 01:42:06PM +0800, Cao jin wrote: Hi, Is anyone gonna take this one? Not sure which tree this should go. Michael, Igor, if you expect this to go through the Machine Core tree, please let me know. -- Yours

Re: [Qemu-devel] [PATCH] pci_register_bar: cleanup

Hi, Is it missed to be pulled? On 03/28/2016 01:55 PM, Marcel Apfelbaum wrote: On 03/25/2016 09:49 AM, Cao jin wrote: place relevant code tegother, make the code easier to read /s/tegother/together Since is already reviewed, maybe the maintainer can fix this. Thanks, Marcel

Re: [Qemu-devel] [PATCH] smbios: fix typo

ping? On 03/29/2016 05:57 PM, Cao jin wrote: sorry mjt, I intended to cc qemu-trivial, now I made it:) On 03/29/2016 05:48 PM, Cao jin wrote: The spec says: "on paragraph (16-byte) boundaries" Signed-off-by: Cao jin --- include/hw/smbios/smbios.h | 2 +- 1 file

Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On Thu, Apr 07, 2016 at 10:10:58AM -0600, Eric Blake wrote: > On 04/07/2016 04:38 AM, Vladimir Sementsov-Ogievskiy wrote: > > On 05.04.2016 16:43, Paolo Bonzini wrote: > >> > >> On 05/04/2016 06:05, Kevin Wolf wrote: > >>> The options I can think of is adding a request field "max number of > >>>

Re: [Qemu-devel] [PATCH v4 1/5] fix some coding style problems

On 04/08/2016 02:29 PM, Markus Armbruster wrote: Cao jin writes: This patch comes along with patch "Add param Error ** for msi_init". What do you want to say with this sentence? I think it could be dropped without loss. According to what I learned