On Fri, 11 Jan 2019 at 23:53, Stefan Hajnoczi wrote:
>
> On Thu, Jan 10, 2019 at 06:59:27PM +0800, Yongji Xie wrote:
> > On Thu, 10 Jan 2019 at 18:25, Stefan Hajnoczi wrote:
> > >
> > > On Wed, Jan 09, 2019 at 07:27:21PM +0800, elohi...@gmail.com wrote:
> > > > From: Xie Yongji
> > > >
> > > >
I believe this feature was just merged by Linus about a week ago, and is
in linux 5.0-rc1:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d548e65904ae43b0637d200a2441fc94e0589c30
--
You received this bug notification because you are a member of qemu-
devel-ml,
Hi folks,
I have some questions about vfio_msix_vector_do_use() in hw/vfio/pci.c, could
you help to explain?
We can see that when guest tries to enable one specific MSIX vector by
unmasking MSIX Vector Control, the access will be trapped and then into
function vfio_msix_vector_do_use(). And
The file no longer uses error_report after review so the header is not
needed either.
Signed-off-by: BALATON Zoltan
---
Forgot to delete this when rewriting after review. This
can be squashed into 7713f5bed in dgibson/qemu/ppc-for-4.0
hw/i2c/smbus_eeprom.c | 1 -
1 file changed, 1 deletion(-)
Cast the kernel start address to the target bit length.
This ensures that we calculate the initrd offset to a valid address for
the architecture.
Signed-off-by: Alistair Francis
Suggested-by: Alexander Graf
Reported-by: Alexander Graf
---
v2:
- Remove old comment
hw/riscv/sifive_e.c | 2 +-
Patchew URL:
https://patchew.org/QEMU/20190109193115.20655-1-marcandre.lur...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190109193115.20655-1-marcandre.lur...@redhat.com
Type: series
Subject: [Qemu-devel] [PATCH
>It should be possible to turn the qtest process into a test
postprocessor,
OSS-Fuzz doesn't support AFL's preprocessors, but adding support shouldn't
be hard.
>It's much harder to
remove the QEMU process as well and turn it into a TestOneInput function.
Got it. I am not familiar with
Don't invalidate TB with the end of zero overhead loop when LBEG or LEND
change. Instead encode the distance from the start of the page where the
TB starts to the LEND in the TB cs_base and generate loopback code when
the next PC matches encoded LEND. Distance to a destination within the
same page
On 1/4/19 5:50 PM, Eric Blake wrote:
>> hmm, as I understand, even if this compatibility exists, it's not a part
>> of standard and nothing about off_t size in POSIX..
>
> off_t allows you to run on older systems with 32-bit offsets and newer
> systems with 64-bit offsets; but these days, even
On 1/12/19 9:27 AM, Max Filippov wrote:
> Maybe "Any other value means that an instruction that ends at this offset
> from the page start may loop back and will need loopback code to be
> generated"?
Much better, thanks.
r~
Patchew URL:
https://patchew.org/QEMU/20190110142955.23254-1-ehabk...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190110142955.23254-1-ehabk...@redhat.com
Type: series
Subject: [Qemu-devel] [PULL 00/10] Machine
On 1/11/19 10:28 PM, no-re...@patchew.org wrote:
> Patchew URL: https://patchew.org/QEMU/201905.8270-1-phi...@redhat.com/
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Message-id: 201905.8270-1-phi...@redhat.com
>
On Fri, Jan 11, 2019 at 2:23 PM Max Filippov wrote:
>
> On Fri, Jan 11, 2019 at 2:17 PM Richard Henderson
> wrote:
> >
> > On 1/12/19 9:14 AM, Max Filippov wrote:
> > >>> +/*
> > >>> + * 0 in the csbase_lend field means that there may not be a
> > >>> loopback
> > >>> +
On Fri, Jan 11, 2019 at 2:17 PM Richard Henderson
wrote:
>
> On 1/12/19 9:14 AM, Max Filippov wrote:
> >>> +/*
> >>> + * 0 in the csbase_lend field means that there may not be a
> >>> loopback
> >>> + * for any instruction that starts inside this page. Any other
> >>>
On 1/12/19 9:14 AM, Max Filippov wrote:
>>> +/*
>>> + * 0 in the csbase_lend field means that there may not be a
>>> loopback
>>> + * for any instruction that starts inside this page. Any other
>>> value
>>> + * means that an instruction that ends at this offset
On Fri, Jan 11, 2019 at 2:09 PM Richard Henderson
wrote:
>
> On 1/12/19 9:01 AM, Max Filippov wrote:
> > Don't invalidate TB with the end of zero overhead loop when LBEG or LEND
> > change. Instead encode the distance from the start of the page where the
> > TB starts to the LEND in the TB
Patchew URL: https://patchew.org/QEMU/201905.8270-1-phi...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 201905.8270-1-phi...@redhat.com
Type: series
Subject: [Qemu-devel] [PATCH] contrib/gitdm: Fix a
On 1/12/19 9:01 AM, Max Filippov wrote:
> Don't invalidate TB with the end of zero overhead loop when LBEG or LEND
> change. Instead encode the distance from the start of the page where the
> TB starts to the LEND in the TB cs_base and generate loopback code when
> the next PC matches encoded
Don't invalidate TB with the end of zero overhead loop when LBEG or LEND
change. Instead encode the distance from the start of the page where the
TB starts to the LEND in the TB cs_base and generate loopback code when
the next PC matches encoded LEND. Distance to a destination within the
same page
Could you clarify what you think the relationship between the qtest
process, QEMU, and afl-fuzz will look like when fuzzing?
Is it something like this:
1. afl-fuzz mutates a buffer, starts a qtest process, and gives the qtest
process the mutated buffer.
2. The qtest process starts a QEMU process
From: Michael Roth
The 'dr_phb_enabled' field of that class can be set as part of
machine-specific init code. It will be used to conditionally
enable creation of DRC objects and device-tree description to
facilitate hotplug of PHBs.
Since we can't migrate this state to older machine types,
Hotplugging PHBs is a machine-level operation, but PHBs reside on the
main system bus, so we register spapr machine as the handler for the
main system bus.
We re-get the phandle of the interrupt controller systematically for
simplicity.
Signed-off-by: Michael Roth
Signed-off-by: Greg Kurz
---
On 1/11/19 2:17 AM, Laurent Vivier wrote:
> On 19/12/2018 05:21, Richard Henderson wrote:
>> Signed-off-by: Richard Henderson
>> ---
>> linux-user/syscall-defs.h | 14
>> linux-user/syscall-file.inc.c | 124 ++
>> linux-user/syscall.c | 93
On 1/11/19 10:49 PM, Max Filippov wrote:
> @@ -706,6 +716,17 @@ static inline void cpu_get_tb_cpu_state(CPUXtensaState
> *env, target_ulong *pc,
> *flags |= xtensa_get_ring(env);
> if (env->sregs[PS] & PS_EXCM) {
> *flags |= XTENSA_TBFLAG_EXCM;
> +} else if
When using the in-kernel interrupt controller, the state of all irqs is
synchronized to KVM at machine reset time. In the case of PHB hotplug, we
will need to synchronize LSIs manually.
Do this for the existing KVM XICS implementation and put a placeholder for
the upcoming KVM XIVE.
From: Michael Roth
PHB hotplug re-uses PHB device tree generation code and passes
it to a guest via RTAS. Doing this requires knowledge of where
exactly in the device tree the node describing the PHB begins.
Provide this via a new optional pointer that can be used to
store the PHB node's start
From: Michael Roth
This is needed to denote a boot-time PHB as being hot-pluggable.
Signed-off-by: Michael Roth
Reviewed-by: David Gibson
Signed-off-by: Greg Kurz
---
hw/ppc/spapr_pci.c |9 +
1 file changed, 9 insertions(+)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
From: Michael Roth
Certain devices types, like memory/CPU, are now being handled using a
hotplug interface provided by a top-level MachineClass. Hotpluggable
host bridges are another such device where it makes sense to use a
machine-level hotplug handler. However, unlike those devices,
From: Michael Roth
Extend the existing EPOW event format we use for PCI
devices to emit PHB plug/unplug events.
Signed-off-by: Michael Roth
Reviewed-by: David Gibson
Signed-off-by: Greg Kurz
---
hw/ppc/spapr_events.c |3 +++
1 file changed, 3 insertions(+)
diff --git
This will be used by PHB hotplug in order to create the "interrupt-map"
property of the PHB node.
Signed-off-by: Greg Kurz
---
hw/intc/spapr_xive.c| 34 --
hw/intc/xics_spapr.c| 28 +++-
hw/ppc/spapr_irq.c |
From: Nathan Fontenot
This add entries to the root OF node to advertise our PHBs as being
DR-capable in accordance with PAPR specification.
Signed-off-by: Nathan Fontenot
Signed-off-by: Michael Roth
Reviewed-by: David Gibson
Signed-off-by: Greg Kurz
---
hw/ppc/spapr.c |8
1
From: Michael Roth
Signed-off-by: Michael Roth
Reviewed-by: David Gibson
Signed-off-by: Greg Kurz
---
hw/ppc/spapr.c | 13 +
hw/ppc/spapr_drc.c | 17 +
include/hw/ppc/spapr.h |1 +
include/hw/ppc/spapr_drc.h |8
4 files
From: Thomas Huth
When compiling with Clang in -std=gnu99 mode, there is a warning/error:
CC ppc64-softmmu/hw/intc/xics_spapr.o
In file included from /home/thuth/devel/qemu/hw/intc/xics_spapr.c:34:
/home/thuth/devel/qemu/include/hw/ppc/xics.h:203:34: error: redefinition of
typedef
To support PHB hotplug we need to clean up lingering references,
memory, child properties, etc. prior to the PHB object being
finalized. Generally this will be called as a result of calling
object_unparent() on the PHB object, which in turn would normally
be called as the result of an unplug()
All this code is used with both the XICS and XIVE interrupt controllers.
Signed-off-by: Greg Kurz
---
hw/ppc/spapr.c |6 +++---
hw/ppc/spapr_events.c |2 +-
hw/ppc/spapr_pci.c |6 +++---
hw/ppc/spapr_vio.c |2 +-
include/hw/pci-host/spapr.h |
This allows to hotplug/unplug PHBs. I could successfully test:
- hotplug/unplug with e1000 device to validate LSIs
- hotplug/unplug with virtio-net device to validate MSIs
- some simple migration scenarios
Changes in v2:
- rebased on current ppc-for-4.0
- added some preliminary cleanup
- call
On 1/12/19 12:10 AM, Bastian Koppelmann wrote:
>
> On 10/31/18 11:18 PM, Richard Henderson wrote:
>>
>> Surely the shri and sari functions need the same shamt >= TARGET_LONG_BITS
>> check as slli. Otherwise RV32 shri should definitely produce an assert in
>> tcg_gen_shri_tl.
>>
>> I did wonder
On Fri, Jan 11, 2019 at 12:53 PM Richard Henderson
wrote:
>
> On 1/11/19 10:49 PM, Max Filippov wrote:
> > +#define LINKABLE_BITS 12
> > +#define LINKABLE_SIZE (1u << LINKABLE_BITS)
> > +#define LINKABLE_MASK (-LINKABLE_SIZE)
>
> What is this for? It seems to be replicating TARGET_PAGE_BITS.
I
On Fri, Jan 11, 2019 at 06:49:53PM +0300, Yury Kotov wrote:
> 10.01.2019, 23:12, "Dr. David Alan Gilbert" :
> > * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> >> Hi,
> >>
> >> The series adds migration capability which allows to skip 'external' RAM
> >> blocks
> >> during migration.
On 1/11/19 10:49 PM, Max Filippov wrote:
> +#define LINKABLE_BITS 12
> +#define LINKABLE_SIZE (1u << LINKABLE_BITS)
> +#define LINKABLE_MASK (-LINKABLE_SIZE)
What is this for? It seems to be replicating TARGET_PAGE_BITS.
r~
On 11/01/19 20:09, Jonathan Metzman wrote:
> Could you clarify what you think the relationship between the qtest
> process, QEMU, and afl-fuzz will look like when fuzzing?
>
> Is it something like this:
> 1. afl-fuzz mutates a buffer, starts a qtest process, and gives the
> qtest process the
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 January 2019 18:10
> To: qemu-devel@nongnu.org
> Cc: Anthony Perard ; Stefano Stabellini
> ; Paul Durrant ; open
> list:X86
> Subject: [PATCH] xen: Fix event channel interface for XenDevice-s
>
>
When qemu dies from a signal, the python code gets a negative
value for exitcode; but signal numbers are positive. Copy the
pattern used in qemu-iotests/iotests.py for reporting a positive
value.
CC: qemu-triv...@nongnu.org
Signed-off-by: Eric Blake
---
scripts/qemu.py | 2 +-
1 file changed,
* Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> 10.01.2019, 23:12, "Dr. David Alan Gilbert" :
> > * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> >> Hi,
> >>
> >> The series adds migration capability which allows to skip 'external' RAM
> >> blocks
> >> during migration. External block is a
On 1/11/19 1:47 PM, Eric Blake wrote:
> Or rather, move its functionality into nbd-server-add. And as
> a side effect, teach qemu-nbd how to export a persistent bitmap
> without having to go through a qemu process and several QMP
> commands.
>
> Based-on:
With the experimental x-nbd-server-add-bitmap command, there was
a window of time where an NBD client could see the export but not
the associated dirty bitmap, which can cause a client that planned
on using the dirty bitmap to be forced to treat the entire image
as dirty as a safety fallback.
Now that nbd-server-add can do the same functionality (well, other
than making the exported bitmap name different than the underlying
bitamp - but we argued that was not essential, since it is just as
easy to create a new non-persistent bitmap with the desired name),
we no longer need the
Having to fire up qemu, then use QMP commands for nbd-server-start
and nbd-server-add, just to expose a persistent dirty bitmap, is
rather tedious. Make it possible to expose a dirty bitmap using
just qemu-nbd (of course, for now this only works when qemu-nbd is
visiting a BDS formatted as
We only have one caller that wants to export a bitmap name,
which it does right after creation of the export. But there is
still a brief window of time where an NBD client could see the
export but not the dirty bitmap, which a robust client would
have to interpret as meaning the entire image
Or rather, move its functionality into nbd-server-add. And as
a side effect, teach qemu-nbd how to export a persistent bitmap
without having to go through a qemu process and several QMP
commands.
Based-on: <20181221093529.23855-1-js...@redhat.com>
[jsnow: 0/11 bitmaps: remove x- prefix from QMP
The existing NBD code had a weird split where nbd_export_new()
created an export but did not add it to the list of exported
names until a later nbd_export_set_name() came along and grabbed
a second reference on the object; later, the first call to
nbd_export_close() drops the second reference
Since we already forbid other nbd-server commands when not
in the right state, it is unlikely that any caller was relying
on a second stop to behave as a silent no-op. Update iotest
223 to show the improved behavior.
Signed-off-by: Eric Blake
---
v3: new patch
---
blockdev-nbd.c |
Our initial implementation of x-nbd-server-add-bitmap put
in a restriction because of incremental backups: in that
usage, we are exporting one qcow2 file (the temporary overlay
target of a blockdev-backup sync:none job) and a dirty bitmap
owned by a second qcow2 file (the source of the
Testing success paths is important, but it's also nice to highlight
expected failure handling, to show that we don't crash, and so that
upcoming tests that change behavior can demonstrate the resulting
effects on error paths.
Add the following errors:
Attempting to export without a running server
On 1/11/19 11:52 AM, Eric Blake wrote:
> On 12/21/18 3:35 AM, John Snow wrote:
>> Presently, we abort transactions in the same order they were processed in.
>> Bitmap commands, though, attempt to restore backup data structures on abort.
>>
>> That's not valid, they need to be aborted in reverse
On 1/11/19 1:14 PM, Markus Armbruster wrote:
> We define 54 macros for the powers of two >= 1024. We use six, in six
> macro definitions. Four of them could just as well use the common MiB
> macro, so do that. The remaining two can't, because they get passed
> to stringify. Replace the macro
Greg Kurz writes:
> On Fri, 11 Jan 2019 16:41:41 +0100
> Paolo Bonzini wrote:
>
>> On 11/01/19 16:28, Alex Bennée wrote:
>> >> Why not g_usleep? It already does a while loop around nanosleep (which
>> >> returns the remaining time in the wait, like select but unlike sleep and
>> >> poll).
>>
пт, 11 янв. 2019 г. в 12:52, Peter Maydell :
>
> On Thu, 10 Jan 2019 at 19:33, Matwey V. Kornilov
> wrote:
> > I am running the same application compiled for aarch64 and armv7l on
> > x86_64 platform using qemu-user-linux tools.
> >
> > I see dramatic performance difference (30 times) between
We define 54 macros for the powers of two >= 1024. We use six, in six
macro definitions. Four of them could just as well use the common MiB
macro, so do that. The remaining two can't, because they get passed
to stringify. Replace the macro by the literal number there.
Slightly harder to read
Back in September, Leonid Block added a whole bunch of macros (commit
540b8492618) to improve readability of qcow2.h a bit (commit
b6a95c6d100). He later used them to fix the "vdi" driver's parameter
cluster_size's default value (commit 3dd5b8f4718). He has now
proposed a further patch[1] to
Hi,
So trying to narrow down the remaining failures in the CI system. There
is one with a patch in flight (use g_usleep instead of sleep) but there
remains two failure modes, both erratic.
tests/qht-par:
I can trigger this on my dev machine with a gprof enabled build:
# QEMU configure log
are available in the git repository at:
>
> git://git.kraxel.org/qemu tags/misc-20190111-pull-request
>
> for you to fetch changes up to 78ac44af547e09bdddc75e41a525cdc8eec60be4:
>
> roms: seabios: Rename CROSS_COMPILE to
On Fri, Jan 11, 2019 at 04:06:54PM +, Alex Bennée wrote:
>
> Paolo Bonzini writes:
>
> > On 11/01/19 16:28, Alex Bennée wrote:
> >>> Why not g_usleep? It already does a while loop around nanosleep (which
> >>> returns the remaining time in the wait, like select but unlike sleep and
> >>>
On 1/11/19 6:23 PM, Eric Blake wrote:
> On 1/11/19 8:14 AM, Leonid Bloch wrote:
>> On 1/10/19 9:18 PM, Eric Blake wrote:
>>> Set the framework up for declaring integer options with an integer
>>> default, instead of our current insane approach of requiring the
>>> default value to be given as a
On Fri, 11 Jan 2019 16:41:41 +0100
Paolo Bonzini wrote:
> On 11/01/19 16:28, Alex Bennée wrote:
> >> Why not g_usleep? It already does a while loop around nanosleep (which
> >> returns the remaining time in the wait, like select but unlike sleep and
> >> poll).
> > Yeah I'm testing that now.
* Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> 10.01.2019, 23:14, "Dr. David Alan Gilbert" :
> > * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> >> RAM migration has a RAMBlock validation stage (flag
> >> RAM_SAVE_FLAG_MEM_SIZE).
> >> In this stage QEMU checks further information about
From: Philippe Mathieu-Daudé
This test is failing on the Travis CI [*] since some time now,
disable it until it get fixed.
[*] https://travis-ci.org/qemu/qemu/builds/474821674
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20190103150951.17592-3-phi...@redhat.com>
Signed-off-by: Eduardo
From: Philippe Mathieu-Daudé
All other variables are set using 'y', which is what the rules.mak
functions expect to parse.
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20190103150951.17592-2-phi...@redhat.com>
Signed-off-by: Eduardo Habkost
---
configure | 2 +-
1 file changed, 1
The following changes since commit e53f7796fbe71a5c7c24ffebf04b4aa9a759da36:
Merge remote-tracking branch
'remotes/ehabkost/tags/machine-next-pull-request' into staging (2019-01-11
13:35:48 +)
are available in the Git repository at:
git://github.com/ehabkost/qemu.git
On Fri, 11 Jan 2019 at 18:13, Anthony PERARD wrote:
>
> On Fri, Jan 11, 2019 at 06:09:41PM +, Anthony PERARD wrote:
> > Patch "xen: add event channel interface for XenDevice-s" makes use of
> > the type xenevtchn_port_or_error_t, but this isn't avaiable before Xen
> > 4.7. Also the function
Patch "xen: add event channel interface for XenDevice-s" makes use of
the type xenevtchn_port_or_error_t, but this isn't avaiable before Xen
4.7. Also the function xen_device_bind_event_channel assign the return
value of xenevtchn_bind_interdomain to channel->local_port but check the
result for
On Fri, Jan 11, 2019 at 06:09:41PM +, Anthony PERARD wrote:
> Patch "xen: add event channel interface for XenDevice-s" makes use of
> the type xenevtchn_port_or_error_t, but this isn't avaiable before Xen
> 4.7. Also the function xen_device_bind_event_channel assign the return
> value of
From: Michael Clark
CSR predicate functions are added to the CSR table.
mstatus.FS and counter enable checks are moved
to predicate functions and two new predicates are
added to check misa.S for s* CSRs and a new PMP
CPU feature for pmp* CSRs.
Processors that don't implement S-mode will trap
on
From: Alistair Francis
Signed-off-by: Alistair Francis
Signed-off-by: Palmer Dabbelt
---
default-configs/riscv32-softmmu.mak | 1 +
default-configs/riscv64-softmmu.mak | 1 +
2 files changed, 2 insertions(+)
diff --git a/default-configs/riscv32-softmmu.mak
From: Michael Clark
Previous CSR code uses csr_read_helper and csr_write_helper
to update CSR registers however this interface prevents
atomic read/modify/write CSR operations; in addition
there is no trap-free method to access to CSRs due
to the monolithic CSR functions call longjmp.
The
The following changes since commit 147923b1a901a0370f83a0f4c58ec1baffef22f0:
Merge remote-tracking branch 'remotes/kraxel/tags/usb-20190108-pull-request'
into staging (2019-01-08 16:07:32 +)
are available in the Git repository at:
git://github.com/palmer-dabbelt/qemu.git
From: Michael Clark
Use the new CSR read/modify/write interface to implement
atomic updates to mip/sip.
Signed-off-by: Michael Clark
Signed-off-by: Alistair Francis
Reviewed-by: Richard Henderson
Signed-off-by: Palmer Dabbelt
---
target/riscv/csr.c | 56
Aleksandar Markovic writes:
> On Monday, January 7, 2019, Alex Bennée wrote:
>
>>
>> Hi,
>>
>> Added a few more updates mostly of IBMers with non corporate emails.
>
>
> Alex, it seems logical to me that you also create a section on gitdm in
> MAINTAINERS, and set yourself as the maintainer
On 1/11/19 11:48 AM, Michael S. Tsirkin wrote:
>>>
diff --git a/pc-bios/optionrom/optrom.h b/pc-bios/optionrom/optrom.h
new file mode 100644
index 00..36f43b43fd
--- /dev/null
+++ b/pc-bios/optionrom/optrom.h
+#include
On 12/21/18 3:35 AM, John Snow wrote:
> Presently, we abort transactions in the same order they were processed in.
> Bitmap commands, though, attempt to restore backup data structures on abort.
>
> That's not valid, they need to be aborted in reverse chronological order.
>
> Replace the QSIMPLEQ
On Fri, Jan 11, 2019 at 06:42:25PM +0100, Stefano Garzarella wrote:
> On Fri, Jan 11, 2019 at 5:27 PM Stefan Hajnoczi wrote:
> >
> > On Fri, Jan 11, 2019 at 02:18:34PM +0100, Stefano Garzarella wrote:
> > > In order to allow other option roms to use these common
> > > useful functions and
On Fri, Jan 11, 2019 at 5:27 PM Stefan Hajnoczi wrote:
>
> On Fri, Jan 11, 2019 at 02:18:34PM +0100, Stefano Garzarella wrote:
> > In order to allow other option roms to use these common
> > useful functions and definitions, this patch put them
> > in a new C header file called optrom.h, and also
On Tue, Dec 18, 2018 at 12:16:29AM +0100, Paolo Bonzini wrote:
> Suggested-by: Daniel P. Berrange
> Signed-off-by: Paolo Bonzini
> ---
> ui/vnc-enc-hextile-template.h | 268 +++
> ui/vnc-enc-zywrle.h | 394 +-
> 2 files changed, 331
On 11/01/19 15:08, Philippe Mathieu-Daudé wrote:
> PixelFormat is used by "ui/console.h" and by "ui/qemu-pixman.h".
ui/console.h already includes ui/qemu-pixman.h, just move it there?
Paolo
> Create the new header "ui/pixelformat.h" to declare this structure,
> and remove the forward
On 1/11/19 10:35 AM, Philippe Mathieu-Daudé wrote:
> The use of a variable named 'exp' prevents includes to import .
>
> Rename it to avoid:
>
> qemu-nbd.c:64:19: error: ‘exp’ redeclared as different kind of symbol
>static NBDExport *exp;
> ^~~
> In file included
On 11.01.2019 17:04, Eric Blake wrote:
> On 1/11/19 10:09 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> I suggested one: Pass large contiguous allocated ranges to the protocol
> driver, but just assume that the allocation status is correct in the
> format layer if they are small.
On Tue, Dec 18, 2018 at 12:16:39AM +0100, Paolo Bonzini wrote:
> Suggested-by: Daniel P. Berrange
> Signed-off-by: Paolo Bonzini
> ---
> crypto/aes.c| 414 -
> crypto/desrfb.c | 594
> 2 files changed, 504
On Fri, Jan 11, 2019 at 03:53:42PM +, Stefan Hajnoczi wrote:
> I'm concerned that this approach to device recovery is invasive and hard
> to test. Instead I would use VIRTIO's Device Status Field
> DEVICE_NEEDS_RESET bit to tell the guest driver that a reset is
> necessary. This is more
On 18/12/18 00:16, Paolo Bonzini wrote:
> Suggested-by: Daniel P. Berrange
> Signed-off-by: Paolo Bonzini
> ---
> ui/vnc-enc-hextile-template.h | 268 +++
> ui/vnc-enc-zywrle.h | 394 +-
> 2 files changed, 331 insertions(+), 331
On 18/12/18 00:16, Paolo Bonzini wrote:
> Suggested-by: Daniel P. Berrange
> Signed-off-by: Paolo Bonzini
> ---
> crypto/aes.c| 414 -
> crypto/desrfb.c | 594
> 2 files changed, 504 insertions(+), 504
On 18/12/18 01:16, Philippe Mathieu-Daudé wrote:
> On 12/18/18 12:16 AM, Paolo Bonzini wrote:
>> Suggested-by: Daniel P. Berrange
>> Signed-off-by: Paolo Bonzini
>> ---
>> crypto/aes.c| 414 -
>> crypto/desrfb.c | 594
On 1/11/19 10:22 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Even a dumb most-recent use cache will speed this up: both the second
>> and third queries above can be avoided because we know that both 0x4
>> and 0x3 the second query at 0x4 can be skipped (0x4 is
>> between our most
On 1/11/19 10:09 AM, Vladimir Sementsov-Ogievskiy wrote:
I suggested one: Pass large contiguous allocated ranges to the protocol
driver, but just assume that the allocation status is correct in the
format layer if they are small.
>>>
>>> So, for fully allocated image, we will call
We can also use vfio_register_event_notifier() helper in
vfio_intx_enable_kvm to set the signalling associated to
VFIO_PCI_INTX_IRQ_INDEX.
Signed-off-by: Eric Auger
---
hw/vfio/pci.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git
The code used to attach the eventfd handler for the ERR and
REQ irq indices can be factorized into a helper. In subsequent
patches we will extend this helper to support other irq indices.
We test the notification is allowed outside of the helper:
respectively check vdev->pci_aer and
This small series introduces the vfio_register_event_notifier()
helper which allows to set up/tear down the VFIO signalling of eventfd
for ERR, REQ and INTX irq indices.
On top of that, a new irq index is planned to signal DMA faults
in nested mode use case. This would use exactly the same
On Fri, 11 Jan 2019 at 14:52, Paolo Bonzini wrote:
>
> The following changes since commit a311f891abf3833c1e4c5a62a6e5b0f1b81f22c3:
>
> Merge remote-tracking branch
> 'remotes/vivier2/tags/linux-user-for-4.0-pull-request' into staging
> (2019-01-10 17:49:54 +)
>
> are available in the Git
In vfio_connect_container() the code that selects the
iommu type can benefit from helpers such as
vfio_iommu_get_type() and vfio_init_container(). As
a result we end up with a switch/case on the iommu type
that makes the code a little bit more readable and ready
for addition of new iommu types.
Whenever the allocation length of a SCSI request is shorter than the size of the
VPD page list, page_idx is used blindly to index into r->buf. Even though
the stores in the insertion sort are protected against overflows, the same is
not
true of the reads and the final store of 0xb0.
This
10.01.2019, 23:14, "Dr. David Alan Gilbert" :
> * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
>> RAM migration has a RAMBlock validation stage (flag RAM_SAVE_FLAG_MEM_SIZE).
>> In this stage QEMU checks further information about RAMBlock:
>> 1. Presence (by idstr),
>> 2. Length (trying to
1 - 100 of 308 matches
Mail list logo
