Add minimal code needed to allow upstream Linux guest to boot.
Cc: Peter Maydell
Cc: Jason Wang
Cc: Philippe Mathieu-Daudé
Cc: Marcel Apfelbaum
Cc: Michael S. Tsirkin
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
Cc: yurov...@gmail.com
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Pet
Use pci_config_size (as opposed to PCI_CONFIG_SPACE_SIZE) in
pci_data_read() and pci_data_write(), so this function would work for
both classic PCI and PCIe use-cases.
Cc: Peter Maydell
Cc: Jason Wang
Cc: Philippe Mathieu-Daudé
Cc: Marcel Apfelbaum
Cc: Michael S. Tsirkin
Cc: qemu-devel@nongnu
Add code needed to get a functional PCI subsytem when using in
conjunction with upstream Linux guest (4.13+). Tested to work against
"e1000e" (network adapter, using MSI interrupts) as well as
"usb-ehci" (USB controller, using legacy PCI interrupts).
Based on "i.MX6 Applications Processor Referenc
On Wed, 7 Feb 2018 15:09:22 +1100
Alexey Kardashevskiy wrote:
> On 07/02/18 11:08, Alex Williamson wrote:
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index e3301dbd27d4..07966a5f0832 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @
On 07/02/18 15:25, Alex Williamson wrote:
> On Wed, 7 Feb 2018 15:09:22 +1100
> Alexey Kardashevskiy wrote:
>> On 07/02/18 11:08, Alex Williamson wrote:
>>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>>> index e3301dbd27d4..07966a5f0832 100644
>>> --- a/include/uapi/linux/v
On Sat, 02/03 10:39, Paolo Bonzini wrote:
> There are cases in which a queued coroutine must be restarted from
> non-coroutine context (with qemu_co_enter_next). In this cases,
> qemu_co_enter_next also needs to be thread-safe, but it cannot use a
> CoMutex and so cannot qemu_co_queue_wait. This
On 02/06/2018 11:15 AM, Peter Maydell wrote:
> My test setup doesn't capture register values from
> before the insn executes...
I have patches for RISU to dump each record written
to the trace file, which does allow one to go back
and examine previous register values.
r~
On 06.02.2018 20:14, Michael Roth wrote:
> Hi everyone,
>
>
> The following new patches are queued for QEMU stable v2.11.1:
>
> https://github.com/mdroth/qemu/commits/stable-2.11-staging
>
> The rele
"Dr. David Alan Gilbert" writes:
> * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
>> 26.01.2018 18:05, Dr. David Alan Gilbert wrote:
>> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
[...]
>> > > most of commands, ported to hmp are done in same style: they ju
It is possible for rate limited writes to keep overshooting a slice's
quota by a tiny amount causing the slice-aligned waiting period to
effectively halve the rate.
Signed-off-by: Wolfgang Bumiller
---
Copied the Ccs from the discussion thread, hope that's fine, as I also
just noticed that for my
Let's provide some links to the videos from FOSDEM and DevConf.
Reviewed-by: Alex Bennée
Reviewed-by: Marc-André Lureau
Reviewed-by: Eduardo Otubo
Signed-off-by: Thomas Huth
---
v2:
- Added link to the virtio 1.1 talk
- Added links to the schedules of the virtualization tracks
_posts/2018
This v2 patch series extends v1 [1] by covering the migration path as
well.
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and
live migration. If the backend is on the persistent memory, QEMU needs
to take proper operations to ensure its writes persistent on the
persistent memory.
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
, let's switch them to use the 'flags' parameters so as to ease future
flag additions.
The existing 'share'
When loading a compressed page to persistent memory, flush CPU cache
after the data is decompressed. Combined with a call to pmem_drain()
at the end of memory loading, we can guarantee those compressed pages
are persistently loaded to PMEM.
Signed-off-by: Haozhong Zhang
---
include/qemu/pmem.h |
When loading a zero page, check whether it will be loaded to
persistent memory If yes, load it by libpmem function
pmem_memset_nodrain(). Combined with a call to pmem_drain() at the
end of RAM loading, we can guarantee all those zero pages are
persistently loaded.
Depending on the host HW/SW conf
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allows users to specify whether the
When loading a xbzrle encoded page to persistent memory, load the data
via libpmem function pmem_memcpy_nodrain() instead of memcpy().
Combined with a call to pmem_drain() at the end of memory loading, we
can guarantee those xbzrle encoded pages are persistently loaded to PMEM.
Signed-off-by: Haoz
When loading a normal page to persistent memory, load its data by
libpmem function pmem_memcpy_nodrain() instead of memcpy(). Combined
with a call to pmem_drain() at the end of memory loading, we can
guarantee all those normal pages are persistenly loaded to PMEM.
Signed-off-by: Haozhong Zhang
--
> From: Laurent Vivier [mailto:laur...@vivier.eu]
> Le 06/02/2018 à 14:30, Pavel Dovgalyuk a écrit :
> >> From: Laurent Vivier [mailto:laur...@vivier.eu]
> > Thanks!
> >
> > By the way, we also handled reset interrupt, but it is not compatible with
> > other m68k
> platforms:
> >
> > @@ -66,8 +66,
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the persistence of its own writes
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss of guest label con
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, February 6, 2018 1:32 AM
> To: Igor Mammedov
> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
> Michael S . Tsirkin
> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming
401 - 422 of 422 matches
Mail list logo
