On 2/21/20 11:45 AM, Dr. David Alan Gilbert wrote:
> Isn't there also a requirement that BARs are powers of two? Wouldn't
> you need to ensure the PMR file is a power of 2 in size?
>
> Dave
Agree, need to make sure it is power of 2.
On 2/21/20 12:32 PM, Stefan Hajnoczi wrote:
> Hi Andrzej,
> After having looked at the PMRWBM part of the spec, I think that the
> Bit 1 mode should be implemented for slightly better performance. Bit
> 0 mode is not well-suited to virtualization for the reasons I
> mentioned in the previous email
This change adds the support for AT_EXECFN and AT_EXECFD auxval.
Signed-off-by: Lirong Yuan
---
linux-user/elfload.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index f3080a1635..7e0f3042f1 100644
--- a/linux-user/
This patch introduces support for PMR that has been defined as part of NVMe 1.4
spec. User can now specify a pmr_file which will be mmap'ed into qemu address
space and subsequently in PCI BAR 2. Guest OS can perform mmio read and writes
to the PMR region that will stay persistent accross system reb
Changes since v1:
- provided support for Bit 1 from PMRWBM register instead of Bit 0 to ensure
improved performance in virtualized environment [1] (Stefan)
- added check if pmr size is power of two in size (David)
- addressed cross compilation build problems reported by CI environment
[1]:
This change allows us to set custom base address for guest programs. It is
needed to allow qemu to work with Thread Sanitizer (TSan), which has specific
boundary definitions for memory mappings on different platforms:
https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/tsan/rtl/tsan_
On 2/20/20 9:34 AM, Ben Gardon wrote:
FWIW, we currently do this eager splitting at Google for live
migration. When the log-dirty-memory flag is set on a memslot we
eagerly split all pages in the slot down to 4k granularity.
As Jay said, this does not cause crippling lock contention because the
Patchew URL: https://patchew.org/QEMU/20200221214614.165338-1-yua...@google.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH] linux-user: Add an argument QEMU_MMAP_BASE to set custom mmap
base address in qemu user mode
Messa
On Fri, Feb 21, 2020 at 2:08 PM Junaid Shahid wrote:
>
> On 2/20/20 9:34 AM, Ben Gardon wrote:
> >
> > FWIW, we currently do this eager splitting at Google for live
> > migration. When the log-dirty-memory flag is set on a memslot we
> > eagerly split all pages in the slot down to 4k granularity.
This change allows us to set custom base address for guest programs. It is
needed to allow qemu to work with Thread Sanitizer (TSan), which has specific
boundary definitions for memory mappings on different platforms:
https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/tsan/rtl/tsan_
> The chip docs don't mention any side effect, they only say that the
> DMA
> IRQ and Error bits in the bus master IDE status reg (bits 2 and 1)
> are
> write 1 to clear
I haven't found any documentation that mention that side effect either.
As you say, it only mentions that you should set the b
On 2020/2/22 上午12:18, Paolo Bonzini wrote:
> On 21/02/20 15:09, Chen Gang wrote:
>>> -/* XXX: test fptags too */
>>> +if (env->fptags[env->fpstt]) {
>>> +env->fpus |= 0x4100; /* Empty */
>>> +return;
>>> +}
>>> +
>> For fpop overflow, this fix is enough, but for me, we s
On 2020/2/22 上午10:10, Chen Gang wrote:
> On 2020/2/22 上午12:18, Paolo Bonzini wrote:
>> On 21/02/20 15:09, Chen Gang wrote:
-/* XXX: test fptags too */
+if (env->fptags[env->fpstt]) {
+env->fpus |= 0x4100; /* Empty */
+return;
+}
+
>>> For fp
On Sat, Feb 22, 2020 at 3:51 AM Alistair Francis wrote:
>
> On Thu, Feb 20, 2020 at 6:43 AM Bin Meng wrote:
> >
> > Update BIOS_FILENAME to consider 32-bit bios image file name.
> >
> > Tested booting Linux v5.5 32-bit image (built from rv32_defconfig
> > plus CONFIG_SOC_SIFIVE) with the default
On Fri, Feb 21, 2020 at 6:53 PM Bin Meng wrote:
>
> On Sat, Feb 22, 2020 at 3:51 AM Alistair Francis wrote:
> >
> > On Thu, Feb 20, 2020 at 6:43 AM Bin Meng wrote:
> > >
> > > Update BIOS_FILENAME to consider 32-bit bios image file name.
> > >
> > > Tested booting Linux v5.5 32-bit image (built
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1814420
Title:
drive-backu
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719282
Title:
Unable to b
On 22/02/20 03:10, Chen Gang wrote:
> Set C1 to 1 if stack overflow occurred; set to 0 otherwise".
>
> In helper_fxam_ST0, I guess, we need "env->fpus |= 0x200" (but I don't
> know wheter it will be conflict with SIGND(temp)). And we have to still
> need foverflow, because all env->fptags being 0
On 2/21/2020 7:31 PM, Stefan Hajnoczi wrote:
> On Thu, Feb 13, 2020 at 09:28:07AM +0800, pannengy...@huawei.com wrote:
>> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
>> index 2eba8b9db0..ed6a5cc03b 100644
>> --- a/hw/block/vhost-user-blk.c
>> +++ b/hw/block/vhost-user-blk.
301 - 319 of 319 matches
Mail list logo
