Hi Greg,
Thank you for spending time reviewing this patch.
On 7/4/16 23:50, Greg Kurz wrote:
On Tue, 15 Mar 2016 00:02:48 +0800
Jevon Qiao wrote:
Ceph as a promising unified distributed storage system is widely used in the
world of OpenStack. OpenStack users deploying Ceph for block (Cinder)
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 NBD_CMD_DISC hits the wire
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 level, if FUA is stil
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
wrote:
> On 24
[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 - if it's qemu's fault
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, which may
>> tweak thi
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 can see the
>> discon
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 a
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
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.
> I
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 this
> should move it
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 client
>> acknowled
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 than
>> allocating e
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
>> ---
>> +/* Maximum size of an export nam
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 +++
1 file changed,
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:
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 -
linux-user/main.c
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| 12 +++-
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(-)
diff --git a/include/qe
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 .
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
---
hw/tpm/tpm_passthrough.c | 2 +-
1
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.
* Register every VF
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 you mean "Require th
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 ?
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
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, logging, and on top of that you need
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|2 +-
tests/vhost-user-bridge.c | 1167 +---
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
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -388,7
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
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -1196
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 7d548d8..b9bf018 100644
--- a/tests/vhost-user-bridge.c
+++ b/tests
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, eventfd,
atomics, it is not so simpl
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 0779ba2..7d548d8 100644
--- a/tests/vhost-user-bridge.c
+++ b/t
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 100644
--- a/docs/specs/vhost-user.txt
+++ b/docs/specs/vhost-u
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
---
docs/specs/vhost-user.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 guess.
msi_init() either succee
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
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 0x before being written
> back
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 stat
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 during NBD_CMD_WRITE, w
* 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 requirem
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 exports". However,
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 incorrectl
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 case
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 seems to make littl
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 protocol recently added t
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 protocol recently added t
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 request, and treat things
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 that returns the same
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.
Thanks for doing this one
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 (only possible in
> n
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 don't even have to
> all
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 Blake
Reviewed-by: A
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 nbd_negotiate_read() which
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 requires INFO,
> but
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.
>
> Signed-off-by: Er
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 NBD_OPT_EXPORT_NAME and NBD
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 (big-endian over the w
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| 2 +-
> nbd/server.c| 4 ++--
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 Er
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 NBD_OPT_EXPORT_NAME), and
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 insertions(+), 1 deletion(-)
>
> diff --git a/nbd/client.c
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
> ---
> nbd/client.c | 41 +
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 description yet,
> we had
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 this isn't
> reall
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 man-in-the-middle attacks, an
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 details of TLS, bu
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 c
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 avail
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
>> option work
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
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 (one P) is res
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
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 m
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
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 be
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 Sinc
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
Signed-o
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 changed, 1 insertion(+), 1
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
> >>> de
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
here(http://lists.nongnu.org/archive/
80 matches
Mail list logo
