On 26/09/2023 13:50, Li Zhijian wrote:
>
>
> On 18/09/2023 22:41, Markus Armbruster wrote:
>> Functions that use an Error **errp parameter to return errors should
>> not also report them to the user, because reporting is the caller's
>> job. When the caller does, the error is reported twice.
> On 25-Sep-2023, at 8:42 PM, Peter Xu wrote:
>
> On Sat, Sep 23, 2023 at 08:03:34AM +0530, Ani Sinha wrote:
>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>> index c0ce896668..c1fb69170f 100644
>> --- a/hw/i386/intel_iommu.c
>> +++ b/hw/i386/intel_iommu.c
>> @@ -3770,9 +3770,9
Code changes that addresses all compiler complaints coming from enabling
-Wshadow flags. Enabling -Wshadow catches cases of local variables shadowing
other local variables or parameters. These makes the code confusing and/or adds
bugs that are difficult to catch.
CC: Markus Armbruster
CC:
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On 18/09/2023 22:41, Markus Armbruster wrote:
> Just for symmetry with qemu_rdma_post_send_control(). Error messages
> lose detail I consider of no use to users.
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Li Zhijian
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On 18/09/2023 22:41, Markus Armbruster wrote:
> Just for consistency with qemu_rdma_write_one() and
> qemu_rdma_write_flush(), and for slightly simpler code.
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Li Zhijian
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On Fri, Sep 22, 2023 at 11:05:59AM -0500, Moger, Babu wrote:
> Date: Fri, 22 Sep 2023 11:05:59 -0500
> From: "Moger, Babu"
> Subject: Re: [PATCH v4 01/21] i386: Fix comment style in topology.h
>
>
> On 9/14/2023 2:21 AM, Zhao Liu wrote:
> > From: Zhao Liu
> >
> > For function comments in this
On Fri, Sep 22, 2023 at 11:03:55AM -0500, Moger, Babu wrote:
> Date: Fri, 22 Sep 2023 11:03:55 -0500
> From: "Moger, Babu"
> Subject: Re: [PATCH v4 00/21] Support smp.clusters for x86 in QEMU
>
> Tested the series on AMD system. Created a VM and ran some basic commands.
>
> Everything looks
On Fri, Sep 22, 2023 at 02:27:18PM -0500, Moger, Babu wrote:
> Date: Fri, 22 Sep 2023 14:27:18 -0500
> From: "Moger, Babu"
> Subject: Re: [PATCH v4 19/21] i386: Use offsets get NumSharingCache for
> CPUID[0x801D].EAX[bits 25:14]
>
>
> On 9/14/2023 2:21 AM, Zhao Liu wrote:
> > From: Zhao
On Fri, Sep 22, 2023 at 02:27:58PM -0500, Moger, Babu wrote:
> Date: Fri, 22 Sep 2023 14:27:58 -0500
> From: "Moger, Babu"
> Subject: Re: [PATCH v4 20/21] i386: Use CPUCacheInfo.share_level to encode
> CPUID[0x801D].EAX[bits 25:14]
>
>
> On 9/14/2023 2:21 AM, Zhao Liu wrote:
> > From: Zhao
Kernel provides the guidance of dynamic MSI-X allocation support of
passthrough device, by clearing the VFIO_IRQ_INFO_NORESIZE flag to
guide user space.
Fetch the flags from host to determine if dynamic MSI-X allocation is
supported.
Originally-by: Reinette Chatre
Signed-off-by: Jing Liu
The vector_use callback is used to enable vector that is unmasked in
guest. The kernel used to only support static MSI-X allocation. When
allocating a new interrupt using "static MSI-X allocation" kernels,
QEMU first disables all previously allocated vectors and then
re-allocates all including the
Guests typically enable MSI-X with all of the vectors masked in the MSI-X
vector table. To match the guest state of device, QEMU enables MSI-X by
enabling vector 0 with userspace triggering and immediately release.
However the release function actually does not release it due to already
using
Changes since v2:
- v2: https://www.mail-archive.com/qemu-devel@nongnu.org/msg989852.html
- Use a bool type to test (vdev->nr_vectors < nr + 1). (Alex)
- Revise comments. (Alex)
- Apply Cédric's and Alex's Reviewed-by.
Changes since v1:
- v1:
During migration restoring, vfio_enable_vectors() is called to restore
enabling MSI-X interrupts for assigned devices. It sets the range from
0 to nr_vectors to kernel to enable MSI-X and the vectors unmasked in
guest. During the MSI-X enabling, all the vectors within the range are
allocated
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On Tue, Sep 26, 2023 at 3:58 AM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> This new version has a simple copyright change in the tcg-cpu.c file,
> patch 01, suggested by Alistair in v3. No other changes made.
>
> All patches acked/reviewed.
>
> Changes from v3:
> - patch 1:
> - use cpu.c
On Mon, 25 Sep 2023, at 18:50, Cédric Le Goater wrote:
> On 9/25/23 09:54, Andrew Jeffery wrote:
>>
>>
>> On Fri, 22 Sep 2023, at 22:51, Cédric Le Goater wrote:
>>> Joel, Andrew,
>>>
>>> On 5/25/19 17:12, Cédric Le Goater wrote:
From: Joel Stanley
The Linux kernel driver was
On Tue, Sep 26, 2023 at 5:09 AM Daniel Henrique Barboza
wrote:
>
> riscv_cpu_realize_tcg() was added to allow TCG cpus to have a different
> realize() path during the common riscv_cpu_realize(), making it a good
> choice to start moving TCG exclusive code to tcg-cpu.c.
>
> Rename it to
On 18/09/2023 22:41, Markus Armbruster wrote:
> Functions that use an Error **errp parameter to return errors should
> not also report them to the user, because reporting is the caller's
> job. When the caller does, the error is reported twice. When it
> doesn't (because it recovered from the
On Tue, Sep 26, 2023 at 6:42 AM Vladimir Sementsov-Ogievskiy
wrote:
>
> Coverity mark this size, got from the buffer as untrasted value, it's
s/untrasted/untrusted/g
> not good to use it as length when writing to file. Make the assertion
> more strict to also check upper bound.
>
>
Hi Salil,
On 9/26/23 06:21, Salil Mehta wrote:
From: Russell King
Sent: Monday, September 25, 2023 9:13 PM
To: Salil Mehta
Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; m...@kernel.org;
james.mo...@arm.com; jean-phili...@linaro.org; Jonathan Cameron
; lorenzo.pieral...@linaro.com;
On Tue, Sep 26, 2023 at 12:13:11AM +0200, Ilya Maximets wrote:
> On 9/25/23 23:24, Michael S. Tsirkin wrote:
> > On Mon, Sep 25, 2023 at 10:58:05PM +0200, Ilya Maximets wrote:
> >> On 9/25/23 17:38, Stefan Hajnoczi wrote:
> >>> On Mon, 25 Sept 2023 at 11:36, Ilya Maximets wrote:
>
> On
On 9/25/23 23:24, Michael S. Tsirkin wrote:
> On Mon, Sep 25, 2023 at 10:58:05PM +0200, Ilya Maximets wrote:
>> On 9/25/23 17:38, Stefan Hajnoczi wrote:
>>> On Mon, 25 Sept 2023 at 11:36, Ilya Maximets wrote:
On 9/25/23 17:12, Stefan Hajnoczi wrote:
> On Mon, 25 Sept 2023 at 11:02,
On Mon, Sep 18, 2023 at 12:42:02PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Michael,
>
> On 6/9/23 08:31, Philippe Mathieu-Daudé wrote:
> > On 30/8/23 15:35, Philippe Mathieu-Daudé wrote:
> > >
> > > This series is now fully reviewed.
> > >
> > > On 10/7/23 11:49, Philippe Mathieu-Daudé wrote:
On Mon, Jul 24, 2023 at 04:54:22PM +0800, Evanzhang wrote:
> under heavy workloads,irq_coalesced could up to 30+,
> after modification EXTERNAL_INTERRUPT reduce by 40%
>
> before:
> Analyze events for all VMs, all VCPUs:
> VM-EXITSamples Samples% Time%
>
>
On Mon, Sep 25, 2023 at 10:58:05PM +0200, Ilya Maximets wrote:
> On 9/25/23 17:38, Stefan Hajnoczi wrote:
> > On Mon, 25 Sept 2023 at 11:36, Ilya Maximets wrote:
> >>
> >> On 9/25/23 17:12, Stefan Hajnoczi wrote:
> >>> On Mon, 25 Sept 2023 at 11:02, Ilya Maximets wrote:
>
> On 9/25/23
On 9/25/23 17:38, Stefan Hajnoczi wrote:
> On Mon, 25 Sept 2023 at 11:36, Ilya Maximets wrote:
>>
>> On 9/25/23 17:12, Stefan Hajnoczi wrote:
>>> On Mon, 25 Sept 2023 at 11:02, Ilya Maximets wrote:
On 9/25/23 16:23, Stefan Hajnoczi wrote:
> On Fri, 25 Aug 2023 at 13:04, Ilya
On Fri, Sep 15, 2023 at 12:25:25PM +0200, Hanna Czenczek wrote:
> RFC:
> https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg04263.html
>
> v1:
> https://lists.nongnu.org/archive/html/qemu-devel/2023-04/msg01575.html
>
> v2:
>
On Fri, Sep 15, 2023 at 12:25:30PM +0200, Hanna Czenczek wrote:
> A virtio-fs device's VM state consists of:
> - the virtio device (vring) state (VMSTATE_VIRTIO_DEVICE)
> - the back-end's (virtiofsd's) internal state
>
> We get/set the latter via the new vhost operations to transfer migratory
>
On Fri, Sep 15, 2023 at 12:25:29PM +0200, Hanna Czenczek wrote:
> vhost_save_backend_state() and vhost_load_backend_state() can be used by
> vhost front-ends to easily save and load the back-end's state to/from
> the migration stream.
>
> Because we do not know the full state size ahead of time,
Hi Russell,
> From: Russell King
> Sent: Monday, September 25, 2023 9:13 PM
> To: Salil Mehta
> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; m...@kernel.org;
> james.mo...@arm.com; jean-phili...@linaro.org; Jonathan Cameron
> ; lorenzo.pieral...@linaro.com;
> lpieral...@kernel.org;
On Fri, Sep 15, 2023 at 12:25:28PM +0200, Hanna Czenczek wrote:
> Add the interface for transferring the back-end's state during migration
> as defined previously in vhost-user.rst.
>
> Signed-off-by: Hanna Czenczek
> ---
> include/hw/virtio/vhost-backend.h | 24 +
>
On Mon, Sep 25, 2023 at 08:03:56PM +, Salil Mehta wrote:
> Looks like some problem with Huawei's mail server server. No patches
> except the cover letter are reaching the qemu-devel mailing-list.
I haven't seen any of the actual patches - just the cover letters.
Was that intentional?
--
25.09.2023 22:40, Vladimir Sementsov-Ogievskiy wrote:
Coverity doesn't like using "untrusted" values, coming from buffers and
fd-s as length to do IO and allocations. And that's make sense. The
"And that makes sense". Just a nitpick in commit comment.
function is used three times with
25.09.2023 22:40, Vladimir Sementsov-Ogievskiy wrote:
NVMeQueuePair::reqs as length NVME_NUM_REQS, which less than
NVME_QUEUE_SIZE by 1.
+if (cid == 0 || cid > NVME_NUM_REQS) {
+warn_report("NVMe: Unexpected CID in completion queue: %" PRIu32
+",
Looks like some problem with Huawei's mail server server. No patches
except the cover letter are reaching the qemu-devel mailing-list.
> From: Salil Mehta
> Sent: Monday, September 25, 2023 8:44 PM
> To: qemu-devel@nongnu.org; qemu-...@nongnu.org
> Cc: Salil Mehta ; m...@kernel.org;
>
Niklas, I'm sorry to lean on you here a little bit - You've been
working on the SATA side of this a bit more often, can you let me know
if you think this patch is safe?
I'm not immediately sure what the impact of applying it is, but I have
some questions about it:
(1) When does ide_dma_cb get
PROLOGUE
To assist in review and set the right expectations from this RFC, please first
read below sections *APPENDED AT THE END* of this cover letter,
1. Important *DISCLAIMER* [Section (X)]
2. Work presented at KVMForum Conference (slides available) [Section (V)F]
3. Organization of
Coverity doesn't like using "untrusted" values, coming from buffers and
fd-s as length to do IO and allocations. And that's make sense. The
function is used three times with "untrusted" nbytes parameter. Let's
introduce at least empirical limit of 1G for it.
While being here make the function
set_time() function doesn't set all the fields, so it's better to
initialize tm structure. And Coverity will be happier about it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/rtc/mc146818rtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rtc/mc146818rtc.c
local_err must be NULL before calling object_property_set_bool(), so we
must clear it on each iteration. Let's also use more convenient
error_reportf_err().
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/pci/pcie_sriov.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff
NVMeQueuePair::reqs as length NVME_NUM_REQS, which less than
NVME_QUEUE_SIZE by 1.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/nvme.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/nvme.c b/block/nvme.c
index b6e95f0b7e..7f11ce1d46 100644
---
This @size parameter often comes from fd. We'd better check it before
doing read and allocation.
Chose 1G as high enough empiric bound.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/core/loader.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git
Coverity doesn't like when the value with unchecked bounds that comes
from fd is used as length for IO or allocation. And really, that's not
a good practice. Let's introduce at least an empirical limits for these
values.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
accel/kvm/kvm-all.c | 15
Add a constant and clear assertion. The assertion also tells Coverity
that we are not going to overflow the array.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/i386/intel_iommu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw/i386/intel_iommu.c
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
io/channel-socket.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/io/channel-socket.c b/io/channel-socket.c
index 02ffb51e99..3a899b0608 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -782,6 +782,11 @@ static int
Explain Coverity that we are not going to overflow vmsg->fds.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
subprojects/libvhost-user/libvhost-user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/subprojects/libvhost-user/libvhost-user.c
b/subprojects/libvhost-user/libvhost-user.c
Coverity mark this size, got from the buffer as untrasted value, it's
not good to use it as length when writing to file. Make the assertion
more strict to also check upper bound.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
softmmu/device_tree.c | 2 +-
1 file changed, 1 insertion(+), 1
Coverity signals that variable as being used uninitialized. And really,
when work with external APIs that's better to zero out the structure,
where we set some fields by hand.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/core/loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Prefer clear assertions instead of possible array overflow.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
util/filemonitor-inotify.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/util/filemonitor-inotify.c b/util/filemonitor-inotify.c
index
Hi! Here are some improvements to handle issues found by Coverity (not
public Coverity site, so there are no CIDs).
Vladimir Sementsov-Ogievskiy (12):
hw/core/loader: load_at(): check size
hw/i386/intel_iommu: vtd_slpte_nonzero_rsvd(): reduce magic numbers
util/filemonitor-inotify:
Upcoming additions to support NBD 64-bit effect lengths allow for the
possibility to distinguish between payload length (capped at 32M) and
effect length (64 bits, although we generally assume 63 bits because
of off_t limitations). Without that extension, only the NBD_CMD_WRITE
request has a
Peform several minor refactorings of how the list of negotiated meta
contexts is managed, to make upcoming patches easier: Promote the
internal type NBDExportMetaContexts to the public opaque type
NBDMetaContexts, and mark exp const. Use a shorter member name in
NBDClient. Hoist calls to
Allow a client to request a subset of negotiated meta contexts. For
example, a client may ask to use a single connection to learn about
both block status and dirty bitmaps, but where the dirty bitmap
queries only need to be performed on a subset of the disk; forcing the
server to compute that
Although extended mode is not yet enabled, once we do turn it on, we
need to reply with extended headers to all messages. Update the low
level entry points necessary so that all other callers automatically
get the right header based on the current mode.
Signed-off-by: Eric Blake
Reviewed-by:
Instead of ignoring the low-level error just to refabricate our own
message to pass to the caller, we can just plumb the caller's errp
down to the low level.
Signed-off-by: Eric Blake
---
v5: set errp on more failure cases [Vladimir], typo fix
v4: new patch [Vladimir]
---
block/nbd.c | 18
Time to start supporting clients that request extended headers. Now
we can finally reach the code added across several previous patches.
Even though the NBD spec has been altered to allow us to accept
NBD_CMD_READ larger than the max payload size (provided our response
is a hole or broken up
All the pieces are in place for a client to finally request extended
headers. Note that we must not request extended headers when qemu-nbd
is used to connect to the kernel module (as nbd.ko does not expect
them, but expects us to do the negotiation in userspace before handing
the socket over to
Update the client code to be able to send an extended request, and
parse an extended header from the server. Note that since we reject
any structured reply with a too-large payload, we can always normalize
a valid header back into the compact form, so that the caller need not
deal with two
Once extended mode is enabled, we need to accept 64-bit status replies
(even for replies that don't exceed a 32-bit length). It is easier to
normalize narrow replies into wide format so that the rest of our code
only has to handle one width. Although a server is non-compliant if
it sends a
The next commit will add support for the optional extension
NBD_CMD_FLAG_PAYLOAD during NBD_CMD_BLOCK_STATUS, where the client can
request that the server only return a subset of negotiated contexts,
rather than all contexts. To make that task easier, this patch
populates the list of contexts to
The NBD spec states that if the client negotiates extended headers,
the server must avoid NBD_REPLY_TYPE_BLOCK_STATUS and instead use
NBD_REPLY_TYPE_BLOCK_STATUS_EXT which supports 64-bit lengths, even if
the reply does not need more than 32 bits. As of this patch,
client->mode is still never
Although extended mode is not yet enabled, once we do turn it on, we
need to accept extended requests for all messages. Previous patches
have already taken care of supporting 64-bit lengths, now we just need
to read it off the wire.
Note that this implementation will block indefinitely on a
v6 was here:
https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg05231.html
Since then:
- patches v6 1-5 included in pull request
- patch v6 6 logic improved, now v7 patch 1
- rebased to master
Still needing review:
- patch 1,6,7,11,12
Eric Blake (12):
nbd/server: Support a request
On Fri, Sep 15, 2023 at 12:25:27PM +0200, Hanna Czenczek wrote:
> Currently, the vhost-user documentation says that rings are to be
> initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
> negotiated. However, by the time of feature negotiation, all rings have
> already been
On Fri, Sep 15, 2023 at 12:25:26PM +0200, Hanna Czenczek wrote:
> For vhost-user devices, qemu can migrate the virtio state, but not the
> back-end's internal state. To do so, we need to be able to transfer
> this internal state between front-end (qemu) and back-end.
>
> At this point, this new
The upcoming patches for 64-bit extensions requires various points in
the protocol to make decisions based on what was negotiated. While we
could easily add a 'bool extended_headers' alongside the existing
'bool structured_reply', this does not scale well if more modes are
added in the future.
On Mon, Sep 04, 2023 at 07:53:10PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 29.08.23 20:58, Eric Blake wrote:
> > Upcoming additions to support NBD 64-bit effect lengths will add a new
> > command flag NBD_CMD_FLAG_PAYLOAD_LEN that needs to be considered in
> > our sanity checks of the
Widen the length field of NBDRequest to 64-bits, although we can
assert that all current uses are still under 32 bits: either because
of NBD_MAX_BUFFER_SIZE which is even smaller (and where size_t can
still be appropriate, even on 32-bit platforms), or because nothing
ever puts us into
The following changes since commit b55e4b9c0525560577384adfc6d30eb0daa8d7be:
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into
staging (2023-09-21 09:32:47 -0400)
are available in the Git repository at:
https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2023-09-25
for
From: "Denis V. Lunev"
The test actually requires Python bindings to libnbd rather than libnbd
itself. Clarify that inside the message.
Signed-off-by: Denis V. Lunev
CC: Kevin Wolf
CC: Hanna Reitz
CC: Eric Blake
CC: Vladimir Sementsov-Ogievskiy
Message-ID:
Add the constants and structs necessary for later patches to start
implementing the NBD_OPT_EXTENDED_HEADERS extension in both the client
and server, matching recent upstream nbd.git (through commit
e6f3b94a934). This patch does not change any existing behavior, but
merely sets the stage for
Upcoming additions to support NBD 64-bit effect lengths will add a new
command flag NBD_CMD_FLAG_PAYLOAD_LEN that needs to be considered in
our sanity checks of the client's messages (that is, more than just
CMD_WRITE have the potential to carry a client payload when extended
headers are in
Once the 64-bit headers extension is enabled, the data layout we send
over the wire for a client request depends on the mode negotiated with
the server. Rather than adding a parameter to nbd_send_request, we
can add a member to struct NBDRequest, since it already does not
reflect on-wire format.
From: "Denis V. Lunev"
We need to check that we are able to create large enough file which is
used as an export base rather than connection URL. Unfortunately, there
are cases when the TEST_IMG_FILE is not defined. We should fallback to
TEST_IMG in that case.
This problem has been detected when
Rename the innermost variables to make the code compile
without warnings when using -Wshadow=local.
Signed-off-by: Thomas Huth
---
hw/m68k/bootinfo.h | 10 --
disas/m68k.c| 8
target/m68k/translate.c | 8
3 files changed, 12 insertions(+), 14
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Warner Losh
Reviewed-by: Richard Henderson
---
bsd-user/bsd-mem.h| 23 +++
bsd-user/freebsd/os-syscall.c | 8
2 files changed, 31 insertions(+)
diff --git
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
bsd-user/bsd-proc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/bsd-user/bsd-proc.c b/bsd-user/bsd-proc.c
index 68410a0aa9..19e39a2f76 100644
From: Kyle Evans
Signed-off-by: Kyle Evans
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
bsd-user/freebsd/os-misc.h| 24
bsd-user/freebsd/os-syscall.c | 6 ++
2 files changed, 30 insertions(+)
diff --git
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
bsd-user/syscall_defs.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/bsd-user/syscall_defs.h b/bsd-user/syscall_defs.h
index
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
bsd-user/syscall_defs.h | 20
1 file changed, 20 insertions(+)
diff --git a/bsd-user/syscall_defs.h b/bsd-user/syscall_defs.h
index
From: Stacey Son
Co-authored-by: Kyle Evans
Signed-off-by: Stacey Son
Signed-off-by: Kyle Evans
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
---
bsd-user/bsd-mem.h| 25 +
bsd-user/freebsd/os-syscall.c | 4
2 files changed, 29
From: Stacey Son
Match linux-user, by manually applying the following commits, in order:
d28b3c90cfad1a7e211ae2bce36ecb9071086129 linux-user: Make sure initial brk(0)
is page-aligned
15ad98536ad9410fb32ddf1ff09389b677643faa linux-user: Fix qemu brk() to not
zero bytes on current page
Upstream the implementation of the following mmap system calls, from the
qemu-bsd-user fork:
mmap(2), munmap(2),
mprotect(2),
msync(2),
mlock(2), munlock(2), mlockall(2), munlockall(2), mincore(2),
madvise(2),
minherit(2),
shm_open(2),shm_open2(2), shm_rename2(2),
From: Stacey Son
Use `WITH_MMAP_LOCK_GUARD` instead of mmap_lock() and mmap_unlock(),
to match linux-user implementation, according to the following commits:
69fa2708a216df715ba5102a0f98468b540a464e linux-user: Use WITH_MMAP_LOCK_GUARD
in target_{shmat,shmdt}
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
---
bsd-user/bsd-mem.h| 39 +++
bsd-user/freebsd/os-syscall.c | 4
2 files changed, 43 insertions(+)
diff --git a/bsd-user/bsd-mem.h
From: Warner Losh
The above system calls are not supported by qemu.
Signed-off-by: Warner Losh
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
---
bsd-user/bsd-mem.h| 18 ++
bsd-user/freebsd/os-syscall.c | 12
2 files changed, 30
From: Stacey Son
Preserve the copyright notice and help with the 'Author' info for
subsequent changes to the file.
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Warner Losh
Reviewed-by: Richard Henderson
---
bsd-user/bsd-mem.h| 64
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
bsd-user/qemu-bsd.h | 45 +
1 file changed, 45 insertions(+)
create mode 100644 bsd-user/qemu-bsd.h
diff --git
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Warner Losh
---
bsd-user/bsd-proc.h | 24
bsd-user/freebsd/os-syscall.c | 8
2 files changed, 32 insertions(+)
diff --git a/bsd-user/bsd-proc.h
From: Stacey Son
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Warner Losh
---
bsd-user/bsd-proc.h | 44 +++
bsd-user/freebsd/os-syscall.c | 9 +++
2 files changed, 53 insertions(+)
diff --git a/bsd-user/bsd-proc.h
From: Stacey Son
To preserve the copyright notice and help with the 'Author' info for
subsequent changes to the file.
Signed-off-by: Stacey Son
Signed-off-by: Karim Taha
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
bsd-user/freebsd/os-misc.h | 28
1 - 100 of 390 matches
Mail list logo
