search for: qemu_get_ram_ptr

...tio core bugs > > when we can't recover from device bugs. > > What do you mean exactly? DMA to invalid memory addresses causes > address_space_map to return a "short read". > > Paolo I mean, first of all, a bunch of virtio_XXX_phys calls. These eventually call qemu_get_ram_ptr, which internally calls qemu_get_ram_block and ramblock_ptr. Both abort on errors. -- MST

...tio core bugs > > when we can't recover from device bugs. > > What do you mean exactly? DMA to invalid memory addresses causes > address_space_map to return a "short read". > > Paolo I mean, first of all, a bunch of virtio_XXX_phys calls. These eventually call qemu_get_ram_ptr, which internally calls qemu_get_ram_block and ramblock_ptr. Both abort on errors. -- MST

We created a 64bit SLES11 SP1 guest, and then used a script to change memory (using mem-set command) periodically (in 1 second): set 1G, set 2G, set 1G, set 2G, and so on. After a few minutes, we encountered QEMU exit due to SIGBUS error. Below is the call trace captured by gdb: The call trace: Program received signal SIGBUS, Bus error. 0x00007f94f74773d7 in memcpy () from /lib64/libc.so.6 (gdb)

...gt; Make sure you are running a guest with less than 2GB of ram, otherwise > you need the patch series that Anthony sent on Friday: > > http://marc.info/?l=qemu-devel&m=131074042905711&w=2 Not this problem. I never alloc more than 2GB for the hvm guest. The call stack in qemu is: qemu_get_ram_ptr ->qemu_map_cache(addr, 0, 1) -> if (!entry->vaddr_base || entry->paddr_index != address_index || !test_bit(address_offset >> XC_PAGE_SHIFT, entry->valid_mapping)) { qemu_remap_bucket(ent...

...an't recover from device bugs. >> >> What do you mean exactly? DMA to invalid memory addresses causes >> address_space_map to return a "short read". >> >> Paolo > > I mean, first of all, a bunch of virtio_XXX_phys calls. > These eventually call qemu_get_ram_ptr, which internally calls > qemu_get_ram_block and ramblock_ptr. > Both abort on errors. address_space_translate and memory_access_size should ensure they don't. Paolo

On Fri, Apr 17, 2015 at 03:59:15PM +0800, Fam Zheng wrote: > Currently, virtio code chooses to kill QEMU if the guest passes any invalid > data with vring. > That has drawbacks such as losing unsaved data (e.g. when > guest user is writing a very long email), or possible denial of service in > a nested vm use case where virtio device is passed through. > > virtio-1 has

On Fri, Apr 17, 2015 at 03:59:15PM +0800, Fam Zheng wrote: > Currently, virtio code chooses to kill QEMU if the guest passes any invalid > data with vring. > That has drawbacks such as losing unsaved data (e.g. when > guest user is writing a very long email), or possible denial of service in > a nested vm use case where virtio device is passed through. > > virtio-1 has

Hi all, this is the long awaited patch series to add xen device model support in qemu; the main author is Anthony Perard. Developing this series we tried to come up with the cleanest possible solution from the qemu point of view, limiting the amount of changes to common code as much as possible. The end result still requires a couple of hooks in piix_pci but overall the impact should be very