search for: is_writeable

This is part of some patches to support sectors > 512. Currently I'm able to boot a Ubuntu kernel but seems that mboot is not working for some reason. This patch add a rdwr_bytes functions which remove the assumption in some places that sector is 512. This function is quite helpful if you are going to read/write a range of bytes to/from the stack without creating stack overflows for free.

This moves the xen_modified_memory call from cpu_physical_memory_map to cpu_physical_memory_unmap because the memory could be migrated before the device model have written to it. But because we need to know the guest address and to avoid rewriting a new function, the call is moved to qemu_invalidate_entry. So this later has to new parameters, the length of the mapping and if it was a write.

On Fri, Jun 17, 2011 at 12:42 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 17 June 2011 09:14, Kostya Serebryany <kcc at google.com> wrote: > >> Maybe the fallback code should just use a function call. Much simpler for >> documentation purposes. > > > Sounds good. > I implemented the asm-free way to report warnings as an option to the llvm

From: Asias He <asias.hejun at gmail.com> This patch is based on Sasha's 'kvm tools: Add support for virtio-mmio' patch. ioeventfds support is added which was missing in the previous one. VQ size/align is still not supported. It adds support for the new virtio-mmio transport layer added in 3.2-rc1. The purpose of this new layer is to allow virtio to work on systems which

From: Asias He <asias.hejun at gmail.com> This patch is based on Sasha's 'kvm tools: Add support for virtio-mmio' patch. ioeventfds support is added which was missing in the previous one. VQ size/align is still not supported. It adds support for the new virtio-mmio transport layer added in 3.2-rc1. The purpose of this new layer is to allow virtio to work on systems which

On Thu, Oct 03, 2019 at 09:54:37PM -0500, Eric Blake wrote: > Although it is unusual for a plugin to shrink size on reopen, it is > not impossible. Failure to check our bounds could result in violating > assumptions in the plugin that all requests are in-bounds. Note that > if the plugin gains a larger size, we merely never access the new tail > of the file (when the NBD protocol

Hi, I would like to improve the debugging experience for ASan. The idea is to have a couple of useful commands in LLDB (probably implemented as Python scripts) that could help the user when they are debugging an ASan-enabled binary. We already have some debugging API (asan_interface.h): // Print the description of addr (useful when debugging in gdb). void __asan_describe_address(void

Hi, What would be our next steps in getting ASan into the LLVM trunk? I'd like to do it in two steps, first for the LLVM part with minimal tests and then for the run-time library and all tests. The current ASan's source repository will probably stay the primary home for the run-time library and tests as we plan to use it in non-LLVM environments. Thanks, --kcc On Fri, Jun 17, 2011 at

This patch adds support for the new virtio-mmio transport layer added in 3.2-rc1. The purpose of this new layer is to allow virtio to work on systems which don't necessarily support PCI, such as embedded systems. To apply the patch on top of the KVM tools tree, you must first pull Linus' tree on top. Also, CONFIG_VIRTIO_MMIO=y should be set in the guest kernel. This is an early RFC,

This patch adds support for the new virtio-mmio transport layer added in 3.2-rc1. The purpose of this new layer is to allow virtio to work on systems which don't necessarily support PCI, such as embedded systems. To apply the patch on top of the KVM tools tree, you must first pull Linus' tree on top. Also, CONFIG_VIRTIO_MMIO=y should be set in the guest kernel. This is an early RFC,

Other drives might want to use SCSI command emulation without going through the SCSI disk abstraction, as this imposes too many limits on the emulation. Signed-off-by: Hannes Reinecke <hare at suse.de> --- block.c | 15 ++ block.h | 3 + block_int.h | 1 + hw/scsi-disk.c | 610 ++++++++++++++++++++++++++++++-------------------------- hw/scsi-disk.h | 3 + 5

Other drives might want to use SCSI command emulation without going through the SCSI disk abstraction, as this imposes too many limits on the emulation. Signed-off-by: Hannes Reinecke <hare at suse.de> --- block.c | 15 ++ block.h | 3 + block_int.h | 1 + hw/scsi-disk.c | 610 ++++++++++++++++++++++++++++++-------------------------- hw/scsi-disk.h | 3 + 5

Although it is unusual for a plugin to shrink size on reopen, it is not impossible. Failure to check our bounds could result in violating assumptions in the plugin that all requests are in-bounds. Note that if the plugin gains a larger size, we merely never access the new tail of the file (when the NBD protocol ever gains dynamic resize support, we'll get to revisit how the retry filter fits

On Sat, Mar 23, 2019 at 05:01:35PM -0400, Michael S. Tsirkin wrote: > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin <mst at redhat.com> writes: [snip] > > >> > Is there any justification to doing that beyond someone putting > > >> > out slow code in the past? > > >> > > >> The

This set of patches add some support for sector size >512. Currently it fixes extlinux, MBR for GPT and ext partitions. Other code is unaffected. This set of patches has been tested on a read Dell machine running a beta firmware.

I figured out the problem. There is zerocopy IO is being done via DMA to a buffer allocated with valloc(). Right now, I am running a hack-fix locally so I can get some other stuff done first. I will propose a proper fix to the list in a few days. On 11/25/2013 10:49 AM, Richard Yao wrote: > I booted a Gentoo Linux installation in QEMU with a 9P rootfs as follows: > > sudo qemu-kvm -cpu

Handle endianness conversion for virtio-1 virtqueues correctly. Note that dataplane now needs to be built per-target. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/block/dataplane/virtio-blk.c | 3 +- hw/scsi/virtio-scsi-dataplane.c | 2 +- hw/virtio/Makefile.objs | 2 +- hw/virtio/dataplane/Makefile.objs | 2 +-

Handle endianness conversion for virtio-1 virtqueues correctly. Note that dataplane now needs to be built per-target. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/block/dataplane/virtio-blk.c | 3 +- hw/scsi/virtio-scsi-dataplane.c | 2 +- hw/virtio/Makefile.objs | 2 +- hw/virtio/dataplane/Makefile.objs | 2 +-

On Tue, 25 Nov 2014 14:24:18 +0100 Cornelia Huck <cornelia.huck at de.ibm.com> wrote: > Handle endianness conversion for virtio-1 virtqueues correctly. > > Note that dataplane now needs to be built per-target. > > Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> > --- We still have the same error as in your previous post... In file included from

Handle endianness conversion for virtio-1 virtqueues correctly. Note that dataplane now needs to be built per-target. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/block/dataplane/virtio-blk.c | 4 +- hw/scsi/virtio-scsi-dataplane.c | 2 +- hw/virtio/Makefile.objs | 2 +- hw/virtio/dataplane/Makefile.objs