If a user specifies a CPU that we don't understand then we want to fall
back to a CPU generated from the ISA string.
At the moment the generated CPU is assumed to be a privledge spec
version 1.10 CPU with an MMU. This can be changed in the future.
Signed-off-by: Alistair Francis
---
v3:
-
Signed-off-by: Alistair Francis
---
hw/riscv/virt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index fc4c6b306e..5b25f028ad 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -400,7 +400,7 @@ static void
Signed-off-by: Alistair Francis
---
linux-user/riscv/target_elf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/linux-user/riscv/target_elf.h b/linux-user/riscv/target_elf.h
index a6716a6aac..9dd65652ee 100644
--- a/linux-user/riscv/target_elf.h
+++ b/linux-user/riscv/target_elf.h
@@ -9,6
On 4/9/19 7:34 PM, Halil Pasic wrote:
On Mon, 8 Apr 2019 19:07:47 +0200
Cornelia Huck wrote:
On Mon, 8 Apr 2019 13:02:12 -0400
Farhan Ali wrote:
On 03/01/2019 04:38 AM, Cornelia Huck wrote:
When we get a solicited interrupt, the start function may have
been cleared by a csch, but we
On 10/04/2019 19.51, Barajas, Felipe wrote:
> Hi,
>
> I am trying to understand who in the QEMU community can give me permission to
> use the QEMU logo in a whitepaper.
> I am an application engineer at Intel and I have prepared some benchmarks
> using QEMU as a solution accelerated by Intel
Hi Dr. David
On Thu, 11 Apr 2019 at 00:57, Dr. David Alan Gilbert
wrote:
> * Catherine Ho (catherine.h...@gmail.com) wrote:
> > Hi Dr. David
> >
> > On Wed, 10 Apr 2019 at 22:59, Dr. David Alan Gilbert <
> dgilb...@redhat.com>
> > wrote:
> >
> > > * Catherine Ho (catherine.h...@gmail.com)
On 4/10/19 2:22 PM, Eric Blake wrote:
> On 4/10/19 12:37 PM, John Snow wrote:
>>
>>
>> On 4/10/19 1:39 AM, Markus Armbruster wrote:
>>> John Snow writes:
>>>
It turns out that having options listed in three places continues to be
a bad idea. I'm still toying with the idea of an
On Wed, Apr 10, 2019 at 05:01:50PM +0200, Igor Mammedov wrote:
>On Wed, 10 Apr 2019 22:27:56 +0800
>Wei Yang wrote:
>
>[...]
>> >@@ -2411,19 +2410,7 @@ build_mcfg_q35(GArray *table_data, BIOSLinker
>> >*linker, AcpiMcfgInfo *info)
>> > mcfg->allocation[0].start_bus_number = 0;
>> >
Paolo Bonzini 于2019年4月10日周三 下午11:55写道：
> On 10/04/19 16:33, Li Qiang wrote:
> > Hi all,
> >
> >
> >
> > I see the link device ‘_PRS’ uses irq line 5, 10, 11 in
> > ‘build_link_dev’ function.
> >
> > But I never see the 5 lines uses in the guest, just uses 10 and 11.
> >
> > Why this happen?
Philippe Mathieu-Daudé writes:
> On 4/10/19 8:34 AM, Alistair Francis wrote:
>> On Tue, Apr 9, 2019 at 10:59 PM Markus Armbruster wrote:
>>> Philippe Mathieu-Daudé writes:
On 4/10/19 7:28 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
[...]
>> BTW how did you
On Wed, Apr 10, 2019 at 9:30 AM Jonathan Behrens wrote:
>
> Unless I'm missing something, the virt board doesn't support HTIF and
> should not be including this header.
Thanks for the patch!
You aren't missing anything, it can be removed.
>
> Jonathan
Can you send a v2 without the uncertainty
This patch series adds a generic RISC-V CPU that can be generated at run
time based on the ISA string specified to QEMU via the -cpu argument. This
is supported on the virt and spike boards allowing users to specify the
RISC-V extensions as well as the ISA version.
As part of the conversion we
On Wed, Apr 10, 2019 at 08:15:32PM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 10, 2019 at 4:45 PM Yoni Bettan wrote:
> > On 4/9/19 4:17 PM, Stefan Hajnoczi wrote:
> > > On Mon, Apr 01, 2019 at 02:18:43PM +0300, Yoni Bettan wrote:
> > The final purpose is to have:
> >
> > 1. device specification
> On 9 Apr 2019, at 17:29, Stefan Hajnoczi wrote:
>
> On Thu, Mar 21, 2019 at 09:55:42AM +0200, Nir Weiner wrote:
>> Originally migration was not possible with vhost-scsi because
>> as part of migration, the source host target SCSI device state
>> needs to be saved and loaded into the
Hi,
On 11/04/2019 03.56, Wei Yang wrote:
> On Mon, Apr 08, 2019 at 09:29:11PM +, Wei Yang wrote:
Thomas,
Thanks for pointing this out, while I have some different idea on how to
fix
this.
The reason of the core dump is errp already been set in
These can now be specified via the command line so we no longer need
these.
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c | 2 --
target/riscv/cpu.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index c792bacd24..9ba77a1983 100644
---
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c | 52 ++
target/riscv/cpu.h | 8 +++
2 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 27be9e412a..c792bacd24 100644
---
Add a generic spike machine (not tied to a version) and deprecate the
spike mahines that are tied to a specific version. As we can now specify
the CPU via the command line we no londer need specific versions of the
spike machines.
Signed-off-by: Alistair Francis
---
hw/riscv/spike.c | 106
On Mon, Apr 08, 2019 at 09:29:11PM +, Wei Yang wrote:
>>>
>>> Thomas,
>>>
>>> Thanks for pointing this out, while I have some different idea on how to fix
>>> this.
>>>
>>> The reason of the core dump is errp already been set in
>>> hotplug_handler_pre_plug(), and this function check acpi
On 10/04/2019 21.48, Stefan Weil wrote:
> This fixes "make check-tcg" on a Debian x86_64 host.
>
> Signed-off-by: Stefan Weil
> ---
> tcg/tci.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/tcg/tci.c b/tcg/tci.c
> index 33edca1903..a6208653e8 100644
> ---
On 09.04.19 22:39, Richard Henderson wrote:
> On 4/9/19 9:46 AM, Stefan Weil wrote:
>> * Calling conventions. The current implementation works on many hosts,
>> but for example not on Sparc. A fix would require simple calling
>> conventions for all helper functions (for example stack based
Philippe Mathieu-Daudé writes:
> On 4/10/19 7:28 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>> On 4/9/19 7:40 PM, Markus Armbruster wrote:
If the value of get_image_size() exceeds INT_MAX / 2 - 1, the
computation of @dt_size overflows to a negative number,
On Tue, Apr 9, 2019 at 10:59 PM Markus Armbruster wrote:
>
> Philippe Mathieu-Daudé writes:
>
> > On 4/10/19 7:28 AM, Markus Armbruster wrote:
> >> Philippe Mathieu-Daudé writes:
> >>> On 4/9/19 7:40 PM, Markus Armbruster wrote:
> If the value of get_image_size() exceeds INT_MAX / 2 -
On 10.04.19 08:07, Thomas Huth wrote:
> That's great, good to know that you're still interested in TCI! ... but
> I think one of the main problems is still that we completely lack test
> coverage for TCI - the code always is in danger to bit-rot if it is not
> tested by default.
Ideally it would
On 09/04/2019 21.46, Stefan Weil wrote:
> On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
>> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
>>> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
>>> Do the various crashes that you illustrate in that cover letter
>>> still
Am Mon, 8 Apr 2019 13:05:07 +0200
schrieb Laszlo Ersek :
> Then build scripts could be updated to invoke:
>
> make -C roms \
> EDK2_BASETOOLS_OPTFLAGS='...' \
> EDK2_BASETOOLS_LDFLAGS='...' \
> efirom
The question remains: 'But why?'.
Why can edk2 not be built with '-fno-pie'
Git bisect shows that 92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855 is the
first bad commit.
Author: Paolo Bonzini
Date: Tue Aug 21 15:31:24 2018 +0200
target/i386: unify masking of interrupts
Interrupt handling depends on various flags in env->hflags or env->hflags2,
and the
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Tuesday, April 09, 2019 11:04 PM
> To: Zhuangyanying
> Cc: marcel.apfelb...@gmail.com; qemu-devel@nongnu.org; Gonglei (Arei)
>
> Subject: Re: [PATCH] msix: fix interrupt aggregation problem at the
>
On Tue, Apr 09, 2019 at 05:44:35PM +0200, Marc-André Lureau wrote:
> min-glib.docker was removed in commit
> e7b3af81597db1a6b55f2c15d030d703c6b2c6ac ("glib: bump min required
> glib library version to 2.40").
>
> Cc: Daniel P. Berrangé
> Signed-off-by: Marc-André Lureau
> ---
>
Hi Kevin,
On 2019/4/9 16:28, Kevin Wolf wrote:
> Am 09.04.2019 um 08:01 hat Markus Armbruster geschrieben:
>> László's last sentence below is "This really needs the attention of the
>> block people." Cc'ing some.
>>
>> Laszlo Ersek writes:
>>
>>> On 04/08/19 15:43, Xiang Zheng wrote:
>
> On Wed 10-04-19 09:38:23, Pankaj Gupta wrote:
> > @@ -64,6 +65,10 @@ static inline bool dax_write_cache_enabled(struct
> > dax_device *dax_dev)
> > {
> > return false;
> > }
> > +static inline bool dax_synchronous(struct dax_device *dax_dev)
> > +{
> > + return true;
> > +}
>
> Is
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 09 April 2019 16:09
> To: Shameerali Kolothum Thodi ;
> qemu-devel@nongnu.org; qemu-...@nongnu.org; eric.au...@redhat.com;
> imamm...@redhat.com
> Cc: peter.mayd...@linaro.org; shannon.zha...@gmail.com;
>
09.04.2019 17:56, Andrey Shinkevich wrote:
> A new test for the patch 'qemu-img convert: ignore read errors'
>
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/253 | 69
> ++
> tests/qemu-iotests/253.out | 4 +++
>
On Sun, Apr 07, 2019 at 05:28:38PM +0530, Sukrit Bhatnagar wrote:
> hvf_handle_io needs the poisoned type CPUArchState as its argument.
> Declaring it if NEED_CPU_H is defined enables include/sysemu/hvf.h
> to be included for common object compilation as well.
>
Reviewed-by: Roman Bolshakov
Patchew URL:
https://patchew.org/QEMU/20190410092652.22616-1-yury-ko...@yandex-team.ru/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
On 09/04/2019 21.46, Stefan Weil wrote:
[...]
> The known problems with the current implementation are
[...]
> * Calling conventions. The current implementation works on many hosts,
> but for example not on Sparc
Is there also a problem with the sparc *target* (i.e. not only sparc
hosts)? TCI does
Paolo Bonzini writes:
> With aio=thread, adaptive polling makes latency worse rather than
> better, because it delays the execution of the ThreadPool's
> completion bottom half.
>
> event_notifier_poll() does run while polling, detecting that
> a bottom half was scheduled by a worker thread,
On 10/04/2019 08.07, Thomas Huth wrote:
> On 09/04/2019 21.46, Stefan Weil wrote:
>> On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
>>> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
Do the various crashes that you
On Wed, 10 Apr 2019 01:00:10 +0200
Laszlo Ersek wrote:
> Repo: https://github.com/lersek/qemu.git
> Branch: edk2_build_v4
>
> Posting a v4 is necessary because patch #6 needs
> - manual conflict resolution against some commits between v4.0.0-rc2 and
> v4.0.0-rc3,
> - and corresponding
On 4/10/19 1:00 AM, Laszlo Ersek wrote:
> Add the files built by the last patch: (compressed) binaries, and the
> cumulative license text that covers them.
>
> Signed-off-by: Laszlo Ersek
> Reviewed-by: Michal Privoznik
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Michael S. Tsirkin
On 4/10/19 1:00 AM, Laszlo Ersek wrote:
> Decompress and install the edk2 firmware blobs as part of "make install",
> unless blob installation was disabled with configure's "--disable-blobs"
> option.
>
> Additionally, decompress the blobs as a pre-requisite for building softmmu
> binaries --
On Sun, Apr 07, 2019 at 05:28:39PM +0530, Sukrit Bhatnagar wrote:
> Keep the calls made to synchronize cpu by all hypervisors in one place
> inside cpu_synchronize_* functions in include/sysemu/hw_accel.h
>
> Cc: Richard Henderson
> Cc: Paolo Bonzini
> Signed-off-by: Sukrit Bhatnagar
> ---
>
On Wed, 10 Apr 2019 09:12:31 +0800
Wei Yang wrote:
> On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
> >Dummy table (with signature "QEMU") creation came from original SeaBIOS
> >codebase. And QEMU would have to keep it around if there were Q35 machine
> >that depended on keeping
In good versions (27e18b8952f8b7a1e26350846f8a0d5a9b33bfb8), calls to
x86_cpu_has_work(), likely due to IRQ 0, returned interchanging true or
false.
In bad versions (92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855), all calls
returned false.
--
You received this bug notification because you are a
On Wed 10-04-19 09:38:23, Pankaj Gupta wrote:
> @@ -64,6 +65,10 @@ static inline bool dax_write_cache_enabled(struct
> dax_device *dax_dev)
> {
> return false;
> }
> +static inline bool dax_synchronous(struct dax_device *dax_dev)
> +{
> + return true;
> +}
Is there a need to define
* Cole Robinson (crobi...@redhat.com) wrote:
> The only caller that checks the error code is looking for != 0,
> so returning false is incorrect.
>
> Fixes: 5aaac467938 "migration: savevm: consult migration blockers"
>
> Signed-off-by: Cole Robinson
Thanks, this was in 3.1.0 so isn't a 4.0
> +static void qmp_screendump_finish(QemuConsole *con, struct qmp_screendump
> *dump)
> +{
> +Error *err = NULL;
> +DisplaySurface *surface;
> +Monitor *prev_mon = cur_mon;
Why this is needed?
> +/*
> + * FIXME: async save with coroutine? it would have to copy or
> +
On Tue, Apr 09, 2019 at 06:10:05PM +0200, Marc-André Lureau wrote:
> Add a function to be called when a graphic update is done.
>
> Declare the QXL renderer as async: render_update_cookie_num counts the
> number of outstanding updates, and graphic_hw_update_done() is called
> when it reaches
09.04.2019 17:56, Andrey Shinkevich wrote:
> The 'qemu-img convert' new command option 'force read' with the key '-R'
> allows converting a damaged image to get all the available information
> in case of the read errors. The program reports read errors and continue
> the image conversion. The
Currently such case is possible for incoming:
QMP: add-fd (fdset = 0, fd of some file):
adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
...
Incoming migration completes and unrefs ioc -> close(33)
QMP: remove-fd (fdset =
On Wed, 10 Apr 2019 at 00:55, Alistair Francis wrote:
>
> The following changes since commit f151f8aca5cf5da24f6eb743a55a2233091ae532:
>
> migration/ram.c: Fix use-after-free in multifd_recv_unfill_packet()
> (2019-04-09 20:46:34 +0100)
>
> are available in the Git repository at:
>
>
On Wed 10-04-19 09:38:24, Pankaj Gupta wrote:
> This patch introduces 'daxdev_mapping_supported' helper
> which checks if 'MAP_SYNC' is supported with filesystem
> mapping. It also checks if corresponding dax_device is
> synchronous. Virtio pmem device is asynchronous and
> does not not support
Cole Robinson wrote:
> The only caller that checks the error code is looking for != 0,
> so returning false is incorrect.
>
> Fixes: 5aaac467938 "migration: savevm: consult migration blockers"
>
> Signed-off-by: Cole Robinson
Reviewed-by: Juan Quintela
On 4/10/19 1:00 AM, Laszlo Ersek wrote:
> In commit b94b330e2333 ("tests: add missing dependency to build
> QTEST_QEMU_BINARY", 2017-07-31), Phil fixed the dependency list of make
> target "check-qtest-%". Namely, the recipe would set QTEST_QEMU_BINARY to
> the softmmu emulator for the emulation
> > This patch introduces 'daxdev_mapping_supported' helper
> > which checks if 'MAP_SYNC' is supported with filesystem
> > mapping. It also checks if corresponding dax_device is
> > synchronous. Virtio pmem device is asynchronous and
> > does not not support VM_SYNC.
> >
> > Suggested-by: Jan
On Mon, Apr 08, 2019 at 04:16:15PM +0100, Paul Durrant wrote:
> To better support use of IOThread-s it will be necessary to be able to set
> the AioContext for each XenEventChannel and hence it is necessary to open a
> separate handle to libxenevtchan for each channel.
>
> This patch stops using
On Apr 10, 2019, at 16:01, Philippe Mathieu-Daudé wrote:
> On 3/6/19 12:01 PM, Paolo Bonzini wrote:
>> On 05/03/19 06:10, Stephen Checkoway wrote:
>>> The SCC/ESCC will briefly stop asserting an interrupt when the
>>> transmit FIFO is filled.
>>>
>>> This code doesn't model the transmit
Please also include this patch in next -rc or final, it fixes 32-bit
compilation:
https://patchew.org/QEMU/20190402073018.17747-1-kraxel%40redhat.com/
([Qemu-devel] [PATCH] curses: fix wchar_t printf warning)
without it I get
ui/curses.c: In function 'get_ucs':
ui/curses.c:456:25: error:
Hi,
Thank you all for the reviews and comments! Since the fixes in sd.c have
gone through the review, I can fix the issue in util/main-loop.c
(mentioned in the reviews of Peter and Liam) in a separate patch.
Thanks,
Lidong
On 4/9/2019 3:39 AM, Liam Merwick wrote:
On 09/04/2019 06:51,
The patch had been merged here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=27a5dc7be6a55b60039e3920
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
>
> On Wed, Apr 10, 2019 at 09:38:22AM +0530, Pankaj Gupta wrote:
> > This patch adds virtio-pmem driver for KVM guest.
> >
> > Guest reads the persistent memory range information from
> > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > creates a nd_region object with the
On Wed, Apr 10, 2019 at 05:35:23PM +0530, Sukrit Bhatnagar wrote:
> On Wed, 10 Apr 2019 at 17:20, Roman Bolshakov wrote:
> >
> > On Sun, Apr 07, 2019 at 05:28:39PM +0530, Sukrit Bhatnagar wrote:
> > > Keep the calls made to synchronize cpu by all hypervisors in one place
> > > inside
On Wed, 10 Apr 2019 10:03:01 -0400 (EDT)
Pankaj Gupta wrote:
> >
> > On Wed, Apr 10, 2019 at 09:38:22AM +0530, Pankaj Gupta wrote:
> > > This patch adds virtio-pmem driver for KVM guest.
> > >
> > > Guest reads the persistent memory range information from
> > > Qemu over VIRTIO and registers
On 4/10/19 4:58 PM, Laszlo Ersek wrote:
> On 04/10/19 06:57, Philippe Mathieu-Daudé wrote:
>> In commit 1cab464136b4 we incorrectly described the
>> EDK2_BASETOOLS_OPTFLAGS can pass CPPFLAGS and CFLAGS
>> options to the EDK2 build tools, but it only expands
>> the CFLAGS (not to the CPPFLAGS).
>>
On Wed, Apr 10, 2019 at 04:20:05PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 10 April 2019 13:57
> > To: Paul Durrant
> > Cc: qemu-devel@nongnu.org; qemu-bl...@nongnu.org;
> > xen-de...@lists.xenproject.org;
On 09.04.19 16:56, Andrey Shinkevich wrote:
> The 'qemu-img convert' new command option 'force read' with the key '-R'
> allows converting a damaged image to get all the available information
> in case of the read errors. The program reports read errors and continue
> the image conversion. The
> >
> > > This patch adds virtio-pmem driver for KVM guest.
> > >
> > > Guest reads the persistent memory range information from
> > > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > > creates a nd_region object with the persistent memory
> > > range information so that existing
On 4/10/19 8:34 AM, Alistair Francis wrote:
> On Tue, Apr 9, 2019 at 10:59 PM Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>> On 4/10/19 7:28 AM, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
> On 4/9/19 7:40 PM, Markus Armbruster wrote:
>> If the value of
You can reproduce this by passing an invalid filter-node-name (like
"1234") to block-commit. In this case the base image is put in
read-write mode but is never reset back to read-only.
Signed-off-by: Alberto Garcia
---
block/commit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 4/10/19 10:24 AM, Alberto Garcia wrote:
> You can reproduce this by passing an invalid filter-node-name (like
> "1234") to block-commit. In this case the base image is put in
> read-write mode but is never reset back to read-only.
>
Is it worth iotest coverage?
> Signed-off-by: Alberto
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 10 April 2019 16:52
> To: Paul Durrant
> Cc: qemu-devel@nongnu.org; xen-de...@lists.xenproject.org;
> qemu-bl...@nongnu.org; Stefano Stabellini
> ; Stefan Hajnoczi ; Kevin Wolf
> ; Max
> Reitz
>
On 10/04/19 16:33, Li Qiang wrote:
> Hi all,
>
>
>
> I see the link device ‘_PRS’ uses irq line 5, 10, 11 in
> ‘build_link_dev’ function.
>
> But I never see the 5 lines uses in the guest, just uses 10 and 11.
>
> Why this happen? Maybe related with the guest?
Because the MADT table tells
On Mon, Apr 08, 2019 at 04:16:17PM +0100, Paul Durrant wrote:
> This patch introduces a poll callback for event channel fd-s and uses
> this to invoke the channel callback function.
>
> To properly support polling, it is necessary for the event channel callback
> function to return a boolean
On Wed, 10 Apr 2019 22:27:56 +0800
Wei Yang wrote:
[...]
> >@@ -2411,19 +2410,7 @@ build_mcfg_q35(GArray *table_data, BIOSLinker
> >*linker, AcpiMcfgInfo *info)
> > mcfg->allocation[0].start_bus_number = 0;
> > mcfg->allocation[0].end_bus_number = PCIE_MMCFG_BUS(info->mcfg_size -
> >
On Tue, Apr 09, 2019 at 02:28:23PM +0200, Paolo Bonzini wrote:
> With aio=thread, adaptive polling makes latency worse rather than
> better, because it delays the execution of the ThreadPool's
> completion bottom half.
>
> event_notifier_poll() does run while polling, detecting that
> a bottom
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 10 April 2019 13:57
> To: Paul Durrant
> Cc: qemu-devel@nongnu.org; qemu-bl...@nongnu.org;
> xen-de...@lists.xenproject.org; Stefano Stabellini
> ; Stefan Hajnoczi ; Kevin Wolf
> ; Max
> Reitz
>
Hi Dr. David
On Wed, 10 Apr 2019 at 22:59, Dr. David Alan Gilbert
wrote:
> * Catherine Ho (catherine.h...@gmail.com) wrote:
> > Hi Igor
> >
> >
> > On Mon, 8 Apr 2019 at 18:35, Igor Mammedov wrote:
> >
> > > On Sun, 7 Apr 2019 22:19:05 -0400
> > > Catherine Ho wrote:
> > >
> > > > Currently
>
> > This patch adds virtio-pmem driver for KVM guest.
> >
> > Guest reads the persistent memory range information from
> > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > creates a nd_region object with the persistent memory
> > range information so that existing 'nvdimm/pmem'
On 4/9/19 4:17 PM, Stefan Hajnoczi wrote:
On Mon, Apr 01, 2019 at 02:18:43PM +0300, Yoni Bettan wrote:
The main goal is to add an example device to Qemu to be used as template or
guideline for contributors when they wish to create a new virtio device.
Another reason for this device is to
On Tue, Apr 09, 2019 at 05:40:38PM +0100, Paul Durrant wrote:
> A recent Xen commit [1] clarified the semantics of sector based quantities
> used in the blkif protocol such that it is now safe to create a xen-block
> device with a logical_block_size != 512, as long as the device only
> connects to
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 10 April 2019 16:23
> To: Paul Durrant
> Cc: qemu-devel@nongnu.org; qemu-bl...@nongnu.org;
> xen-de...@lists.xenproject.org; Stefano Stabellini
> ; Stefan Hajnoczi ; Kevin Wolf
> ; Max
> Reitz
>
tmpfs does not support O_DIRECT. Detect this case, and skip flipping
@direct if the filesystem does not support it.
Fixes: bf3e50f6239090e63a8ffaaec971671e66d88e07
Signed-off-by: Max Reitz
---
tests/qemu-iotests/245 | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
Unless I'm missing something, the virt board doesn't support HTIF and
should not be including this header.
Jonathan
Signed-off-by: Jonathan Behrens
---
hw/riscv/virt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index fc4c6b306e..3526463034 100644
---
On 4/10/19 11:29 AM, Max Reitz wrote:
> tmpfs does not support O_DIRECT. Detect this case, and skip flipping
> @direct if the filesystem does not support it.
>
> Fixes: bf3e50f6239090e63a8ffaaec971671e66d88e07
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/245 | 10 --
> 1 file
On 10.04.19 18:39, Eric Blake wrote:
> On 4/10/19 11:29 AM, Max Reitz wrote:
>> tmpfs does not support O_DIRECT. Detect this case, and skip flipping
>> @direct if the filesystem does not support it.
>>
>> Fixes: bf3e50f6239090e63a8ffaaec971671e66d88e07
>> Signed-off-by: Max Reitz
>> ---
>>
On 09/04/19 11:42, Thomas Huth wrote:
>> -static void tmp105_set16(I2CAdapter *i2c, uint8_t addr, uint8_t reg,
>> - uint16_t value)
>> -{
>> -uint8_t cmd[3];
>> -uint8_t resp[2];
>> -
>> -cmd[0] = reg;
>> -cmd[1] = value >> 8;
>> -cmd[2] = value & 255;
* Yury Kotov (yury-ko...@yandex-team.ru) wrote:
> Currently such case is possible for incoming:
> QMP: add-fd (fdset = 0, fd of some file):
> adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
> QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
> ...
> Incoming migration
On Wed, Apr 10, 2019 at 11:08:33AM +0200, Igor Mammedov wrote:
>On Wed, 10 Apr 2019 09:12:31 +0800
>Wei Yang wrote:
>
>> On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
>> >Dummy table (with signature "QEMU") creation came from original SeaBIOS
>> >codebase. And QEMU would have to
On Wed, 10 Apr 2019 22:01:53 +0800
Wei Yang wrote:
> On Wed, Apr 10, 2019 at 11:08:33AM +0200, Igor Mammedov wrote:
> >On Wed, 10 Apr 2019 09:12:31 +0800
> >Wei Yang wrote:
> >
> >> On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
> >> >Dummy table (with signature "QEMU")
On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
>Dummy table (with signature "QEMU") creation came from original SeaBIOS
>codebase. And QEMU would have to keep it around if there were Q35 machine
>that depended on keeping ACPI tables blob constant size. Luckily there
>were no
Hi all,
I see the link device ‘_PRS’ uses irq line 5, 10, 11 in ‘build_link_dev’
function.
But I never see the 5 lines uses in the guest, just uses 10 and 11.
Why this happen? Maybe related with the guest?
Thanks,
Li Qiang
> +
> +static int virtio_pmem_probe(struct virtio_device *vdev)
> +{
> + int err = 0;
> + struct resource res;
> + struct virtio_pmem *vpmem;
> + struct nvdimm_bus *nvdimm_bus;
> + struct nd_region_desc ndr_desc = {};
> + int nid = dev_to_node(>dev);
> + struct
On Wed, 10 Apr 2019 at 17:20, Roman Bolshakov wrote:
>
> On Sun, Apr 07, 2019 at 05:28:39PM +0530, Sukrit Bhatnagar wrote:
> > Keep the calls made to synchronize cpu by all hypervisors in one place
> > inside cpu_synchronize_* functions in include/sysemu/hw_accel.h
> >
> > Cc: Richard Henderson
On Wed, 10 Apr 2019 09:38:22 +0530
Pankaj Gupta wrote:
> This patch adds virtio-pmem driver for KVM guest.
>
> Guest reads the persistent memory range information from
> Qemu over VIRTIO and registers it on nvdimm_bus. It also
> creates a nd_region object with the persistent memory
> range
Hi,
10.04.2019, 16:58, "Dr. David Alan Gilbert" :
> * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
>> Currently such case is possible for incoming:
>> QMP: add-fd (fdset = 0, fd of some file):
>> adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
>> QMP: migrate-incoming (uri = "fd:33"):
* Catherine Ho (catherine.h...@gmail.com) wrote:
> Hi Igor
>
>
> On Mon, 8 Apr 2019 at 18:35, Igor Mammedov wrote:
>
> > On Sun, 7 Apr 2019 22:19:05 -0400
> > Catherine Ho wrote:
> >
> > > Currently it is not forbidden to use "-object
> > memory-backend-file,share=on"
> > > and together with
On Mon, Apr 08, 2019 at 04:16:16PM +0100, Paul Durrant wrote:
> This patch adds an AioContext parameter to xen_device_bind_event_channel()
> and then uses aio_set_fd_handler() to set the callback rather than
> qemu_set_fd_handler().
>
> Signed-off-by: Paul Durrant
> ---
> @@ -943,6 +944,7 @@
On Wed, Apr 10, 2019 at 02:24:26PM +0200, Cornelia Huck wrote:
> On Wed, 10 Apr 2019 09:38:22 +0530
> Pankaj Gupta wrote:
>
> > This patch adds virtio-pmem driver for KVM guest.
> >
> > Guest reads the persistent memory range information from
> > Qemu over VIRTIO and registers it on nvdimm_bus.
On 09/04/2019 17.37, Stephen Checkoway wrote:
>
>
> On Apr 9, 2019, at 02:13, Thomas Huth wrote:
>
>> We'd like to get rid of global_qtest in the long run (since it is
>> causing trouble for tests that run multiple instances of QEMU in
>> parallel, e.g. migration tests)... so if it is
On Tue, Apr 09, 2019 at 02:28:23PM +0200, Paolo Bonzini wrote:
Why is this 4.0 material? It's not a 4.0 regression and tweaking the
event loop is risky. I suggest waiting for 4.1.
> With aio=thread, adaptive polling makes latency worse rather than
> better, because it delays the execution of
1 - 100 of 155 matches
Mail list logo
