From: Olaf Hering
Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not
required anymore.
Signed-off-by: Olaf Hering
Reviewed-by: Thomas Huth
Message-Id: <20201124211925.4194-1-o...@aepfle.de>
Signed-off-by: Paolo Bonzini
---
configure | 3 ---
1 file changed, 3
When the persistent memory beacked by a file, a cpu cache flush instruction
is not sufficient to ensure the stores are correctly flushed to the media.
The patch implements the async hcalls for flush operation on demand from the
guest kernel.
The device option sync-dax is by default off and
The patch adds support for async hcalls at the DRC level for the
spapr devices. To be used by spapr-scm devices in the patch/es to follow.
Signed-off-by: Shivaprasad G Bhat
---
hw/ppc/spapr_drc.c | 146
include/hw/ppc/spapr_drc.h | 25
The nvdimm devices are expected to ensure write persistent during power
failure kind of scenarios.
The libpmem has architecture specific instructions like dcbf on power
to flush the cache data to backend nvdimm device during normal writes.
Qemu - virtual nvdimm devices are memory mapped. The
Le 28/10/2020 à 22:38, Tobias Koch a écrit :
> If mremap succeeds, an additional check is performed to ensure that the
> new address range fits into the target address space. This check was
> previously perfomed in host address space, with the upper bound fixed to
> abi_ulong.
>
> This patch
Free the 'sioc' when the qio_channel_socket_connect_sync() fails.
Reported-by: Euler Robot
Signed-off-by: Alex Chen
---
ui/vnc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ui/vnc.c b/ui/vnc.c
index 49235056f7..dae56e9493 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3743,6 +3743,7 @@
>> why ? we would stop claiming IPIs in spapr_irq_init() and so
>> they won't appear as being valid anymore, at boot time or
>> restore time.
>>
>
> If we don't claim the IPIs in spapr_irq_init() anymore then
> we must at least claim them on the path of H_INT_GET_SOURCE_INFO
> otherwise it will
Hi,
After reading everyone's opinions, we have a rough idea for this issue.
One key point is whether it is necessary to setup the config space before
the device can accept further migration data. I think it is decided by
the vendor driver, so we can simply ask the vendor driver about it in
Ben Widawsky writes:
> On 20-11-13 08:47:59, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>> > On 11/10/20 11:47 PM, Ben Widawsky wrote:
>> >> A CXL memory device (AKA Type 3) is a CXL component that contains some
>> >> combination of volatile and persistent memory. It also implements the
On Wed, Nov 25, 2020 at 10:51:05AM +0100, Greg Kurz wrote:
> On Wed, 25 Nov 2020 13:39:47 +1100
> David Gibson wrote:
>
> > On Mon, Nov 23, 2020 at 12:51:08PM +0100, Greg Kurz wrote:
> > > On Mon, 23 Nov 2020 16:11:30 +1100
> > > David Gibson wrote:
> > >
> > > > On Sat, Nov 21, 2020 at
[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/1719870
Title:
Converting
[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/1713825
Title:
Booting
[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/1721952
Title:
Network
[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/1779650
Title:
The
[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/1776760
Title:
Loading
[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/1722857
Title:
Missing
An alternative is of course to allow g_error to be called.
One might restrict tests to not call it, but it might be impractical to impose
that on all code that goes into a test.
One will need to find a way to get glib to not call G_BREAKPOINT for this case.
if (debugger_present && breakpoint)
Signed-off-by: Eldon Stegall
---
_posts/2020-11-26-qemu-advent-announce.md | 39 +++
1 file changed, 39 insertions(+)
create mode 100644 _posts/2020-11-26-qemu-advent-announce.md
diff --git a/_posts/2020-11-26-qemu-advent-announce.md
On Wed, Nov 25, 2020 at 11:43:26PM +0100, Greg Kurz wrote:
> On Mon, 23 Nov 2020 14:33:55 +1100
> David Gibson wrote:
>
> > On Fri, Nov 20, 2020 at 06:46:40PM +0100, Greg Kurz wrote:
> > > We're going to kill the "nr_ends" field in a subsequent patch.
> > > Prepare ground by using an helper
On 2020/11/25 下午8:03, Eugenio Perez Martin wrote:
On Wed, Nov 25, 2020 at 8:09 AM Jason Wang wrote:
On 2020/11/21 上午2:50, Eugenio Pérez wrote:
This series enable vDPA software assisted live migration for vhost-net
devices. This is a new method of vhost devices migration: Instead of
relay
On 201125 1539, Doug Evans wrote:
> Hi.
>
> I can run a subset of qtest tests with "make check-qtest-TARGET", but
> that's the limit of the granularity that I can find. Why would one want
> more granularity? When adding a test one wants the edit/test cycle as short
> as possible and needlessly
Public bug reported:
I stumbled on this writing a new test, using tests/qtest/e1000e-test.c
as a template.
g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get
run.
This in turn means qemu is not killed, which hangs the test because the
tap-driver.pl script hangs
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1826827
Title:
dtc crash; pnv_dt_serial cannot find lpc's phandle
Status in QEMU:
Fix
On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> Media eXtension Unit is a SIMD extension from Ingenic.
>
> Extract 2900 lines from the huge translate.c to a new file,
> 'vendor-xburst-mxu_translate.c.inc'. As there are too many
> inter-dependencies we don't compile it as another object,
>
On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> LoongEXTs are general-purpose extensions from the LoongISA.
>
> Extract 650 lines of translation routines to
> 'vendor-loong-ext_translate.c.inc'.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/mips/translate.c
On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> We have ~400 lines of MSA helpers in the generic op_helper.c,
> move them with the other helpers in 'mod-msa_helper.c'.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/mips/mod-msa_helper.c | 392 ++
>
On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> MSA means 'MIPS SIMD Architecture' and is defined as a Module by
> MIPS.
> To keep the directory sorted, we use the 'mod' prefix for MIPS
> modules. Rename msa_helper.c as mod-msa_helper.c.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
>
On 11/23/20 12:44 PM, Philippe Mathieu-Daudé wrote:
> Use the FloatRoundMode enum type introduced in commit 3dede407cc6
> ("softfloat: Name rounding mode enum") instead of 'unsigned int'.
>
> Suggested-by: Richard Henderson
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/mips/internal.h
Hi.
I can run a subset of qtest tests with "make check-qtest-TARGET", but
that's the limit of the granularity that I can find. Why would one want
more granularity? When adding a test one wants the edit/test cycle as short
as possible and needlessly running other tests is a pain.
It'd be really
On Mon, 23 Nov 2020 14:33:55 +1100
David Gibson wrote:
> On Fri, Nov 20, 2020 at 06:46:40PM +0100, Greg Kurz wrote:
> > We're going to kill the "nr_ends" field in a subsequent patch.
> > Prepare ground by using an helper instead of peeking into
> > the sPAPR XIVE structure directly.
> >
> >
On Wed, Nov 25, 2020 at 03:56:30PM -0500, Eduardo Habkost wrote:
> This series gets rid of most of the code in arch_init.c. It
> moves the QEMU_ARCH macro definitions to corresponding cpu.h
> files, and gets rid of kvm_available() and xen_available().
>
For the series:
Reviewed-by: Roman
time element is deprecated on new input_event structure in kernel's
input.h [1]
This will avoid the following build failure:
hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status':
hw/input/virtio-input-host.c:198:28: error: 'struct input_event' has no member
named 'time'
On 25/11/20 21:35, Sunil Muthuswamy wrote:
> Sorry, this has missed the 5.2 soft freeze. Can you please resend it in
about a month?
Paolo, is the branch open now for this kind of change? Where can I track
the branch status?
Hi, you can track it at https://wiki.qemu.org/Planning/5.2.
... for consistency with "-d help".
Signed-off-by: Doug Evans
---
trace/control.c | 12 ++--
trace/control.h | 3 ++-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/trace/control.c b/trace/control.c
index b82fb87316..cd04dd4e0c 100644
--- a/trace/control.c
+++
env->boot_info is only set in some ARM startup paths, so we cannot
rely on it to support the SYS_HEAPINFO semihosting function. When not
available, fallback to finding a RAM memory region containing the
current stack and use the base of that.
Signed-off-by: Keith Packard
---
These are part of Semihosting for AArch32 and AArch64 Release 2.0
Signed-off-by: Keith Packard
---
hw/semihosting/common-semi.c | 16
include/qemu/timer.h | 2 ++
util/qemu-timer-common.c | 4
3 files changed, 22 insertions(+)
diff --git
Part of Semihosting for AArch32 and AArch64 Release 2.0
Signed-off-by: Keith Packard
---
hw/semihosting/common-semi.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index 9a04d98e4e..fda0e714ef 100644
---
Part of Semihosting for AArch32 and AArch64 Release 2.0
Signed-off-by: Keith Packard
---
hw/semihosting/common-semi.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/hw/semihosting/common-semi.c b/hw/semihosting/common-semi.c
index
Adapt the arm semihosting support code for RISCV. This implementation
is based on the standard for RISC-V semihosting version 0.2 as
documented in
https://github.com/riscv/riscv-semihosting-spec/releases/tag/0.2
Signed-off-by: Keith Packard
---
v2:
Update PC after exception is
This makes all of the internal interfaces architecture-independent and
renames the internal functions to use the 'common_semi' prefix instead
of 'arm' or 'arm_semi'.
To do this, some new architecture-specific internal helper functions
were created:
static inline target_ulong
This commit renames two files which provide ARM semihosting support so
that they can be shared by other architectures:
1. target/arm/arm-semi.c -> hw/semihosting/common-semi.c
2. linux-user/arm/semihost.c -> linux-user/semihost.c
The build system was modified use a new config variable,
This series adds support for RISC-V Semihosting, version 0.2 as
specified here:
https://github.com/riscv/riscv-semihosting-spec/releases/tag/0.2
This specification references the ARM semihosting release 2.0 as specified here:
The public API is now defined in
hw/semihosting/common-semi.h. do_common_semihosting takes CPUState *
instead of CPUARMState *. All internal functions have been renamed
common_semi_ instead of arm_semi_ or arm_. Aside from the API change,
there are no functional changes in this patch.
On Wed, Nov 25, 2020 at 11:28 PM Peter Maydell
wrote:
> On Wed, 25 Nov 2020 at 19:23, Stefan Weil wrote:
> >
> > Pass cpu instead of cpu_family to the NSIS installer script.
> >
> > That script checks for "x86_64" which is the cpu value,
> > while cpu_family is "x86".
> >
> > Signed-off-by:
On Wed, Nov 25, 2020 at 11:22 PM Stefan Weil wrote:
> Pass cpu instead of cpu_family to the NSIS installer script.
>
> That script checks for "x86_64" which is the cpu value,
> while cpu_family is "x86".
>
> Signed-off-by: Stefan Weil
>
Reviewed-by: Marc-André Lureau
---
> meson.build | 2
On Nov 17 16:32, Keith Busch wrote:
> On Thu, Nov 12, 2020 at 08:36:39PM +0100, Klaus Jensen wrote:
> > On Nov 5 11:53, Dmitry Fomichev wrote:
> > > @@ -133,6 +300,12 @@ static Property nvme_ns_props[] = {
> > > DEFINE_BLOCK_PROPERTIES(NvmeNamespace, blkconf),
> > >
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1833053
Title:
qemu guest crashes on spice client USB redirected device removal
Status in QEMU:
The only declarations in arch_init.h are the `arch_type` variable
and the QEMU_ARCH_* constants. Stop including arch_init.h from
code that don't use neither.
Patch generated automatically using the command:
$ sed -i -e '/#include "sysemu.arch_init.h"/d' \
$(comm -23 \
<(git grep -l
Am 25.11.20 um 20:28 schrieb Peter Maydell:
On Wed, 25 Nov 2020 at 19:23, Stefan Weil wrote:
Pass cpu instead of cpu_family to the NSIS installer script.
That script checks for "x86_64" which is the cpu value,
while cpu_family is "x86".
Signed-off-by: Stefan Weil
---
meson.build | 2 +-
The function can be replaced with accel_available("xen").
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: qemu-devel@nongnu.org
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: xen-de...@lists.xenproject.org
Cc: Richard Henderson
Cc: Claudio Fontana
Cc: Roman
The only caller can use accel_available("kvm") instead.
Signed-off-by: Eduardo Habkost
---
Cc: Markus Armbruster
Cc: qemu-devel@nongnu.org
Cc: Paolo Bonzini
Cc: k...@vger.kernel.org
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Claudio Fontana
Cc: Roman Bolshakov
---
The only declarations in arch_init.h are related to the arch_type
variable (which is a useful feature that allows us to simplify
command line option handling). Rename the header to reflect its
purpose.
Signed-off-by: Eduardo Habkost
---
Cc: Markus Armbruster
Cc: Kevin Wolf
Cc: Max Reitz
Cc:
This function will be used to replace the xen_available() and
kvm_available() functions from arch_init.c.
Signed-off-by: Eduardo Habkost
---
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Claudio Fontana
Cc: Roman Bolshakov
---
include/sysemu/accel.h | 1 +
accel/accel.c | 5 +
2
This series gets rid of most of the code in arch_init.c. It
moves the QEMU_ARCH macro definitions to corresponding cpu.h
files, and gets rid of kvm_available() and xen_available().
After this series, only two things remain in arch_init.c:
- the arch_type variable, which seems to be a useful
Instead of a collection of #ifdefs on arch_init.c, define
QEMU_ARCH inside each cpu.h file.
Signed-off-by: Eduardo Habkost
---
Cc: Richard Henderson
Cc: Peter Maydell
Cc: Michael Rolnik
Cc: Sarah Harris
Cc: "Edgar E. Iglesias"
Cc: Paolo Bonzini
Cc: Eduardo Habkost
Cc: Michael Walle
Cc:
> Sorry, this has missed the 5.2 soft freeze. Can you please resend it in
> about a month?
>
> Thanks,
>
> Paolo
Paolo, is the branch open now for this kind of change? Where can I track
the branch status?
On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > > Hello,
> > >
> > > We recently found out that some softwares are effectively crashing
Le mer. 25 nov. 2020 à 13:06, Gerd Hoffmann a écrit :
>
> On Wed, Nov 18, 2020 at 09:38:24PM +0100, Fabrice Fontaine wrote:
> > time element is deprecated on new input_event structure in kernel's
> > input.h [1]
> >
> > This will avoid the following build failure:
> >
> >
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
>
>
> On 11/26/2020 12:33 AM, Dr. David Alan Gilbert wrote:
> > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > >
> > >
> > > On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:
> > > > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > > > >
No I never did. I reached out to try and get info on how to run or get a
backtrack and never heard anything. I finally gave up and ended up
selling the computer since I never got it working how I wanted to.
> On Nov 25, 2020, at 10:20 AM, Thomas Huth <1821...@bugs.launchpad.net> wrote:
>
> Hi!
On 11/26/2020 12:33 AM, Dr. David Alan Gilbert wrote:
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
Header file where CONFIG_VFIO is defined is not included in migration.c
file. Include
On Wed, 25 Nov 2020 at 19:23, Stefan Weil wrote:
>
> Pass cpu instead of cpu_family to the NSIS installer script.
>
> That script checks for "x86_64" which is the cpu value,
> while cpu_family is "x86".
>
> Signed-off-by: Stefan Weil
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+),
Pass cpu instead of cpu_family to the NSIS installer script.
That script checks for "x86_64" which is the cpu value,
while cpu_family is "x86".
Signed-off-by: Stefan Weil
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index
On 25.11.2020 21:43, Dr. David Alan Gilbert wrote:
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
On 24.11.2020 20:57, Dr. David Alan Gilbert wrote:
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
Implemented support for the whole RAM block memory
protection/un-protection.
On 25.11.2020 21:41, Dr. David Alan Gilbert wrote:
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
On 25.11.2020 16:08, Dr. David Alan Gilbert wrote:
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
In this particular implementation the same single migration
thread is responsible
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
>
>
> On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:
> > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > > Header file where CONFIG_VFIO is defined is not included in migration.c
> > > file. Include config devices header file in
Signed-off-by: Alberto Garcia
Suggested-by: Maxim Levitsky
---
tests/qemu-iotests/313 | 103 +
tests/qemu-iotests/313.out | 29 +++
tests/qemu-iotests/group | 1 +
3 files changed, 133 insertions(+)
create mode 100755 tests/qemu-iotests/313
On 11/25/2020 3:00 PM, Dr. David Alan Gilbert wrote:
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
Header file where CONFIG_VFIO is defined is not included in migration.c
file. Include config devices header file in migration.c.
Fixes: 3710586caa5d ("qapi: Add VFIO devices migration stats
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> On 24.11.2020 20:57, Dr. David Alan Gilbert wrote:
> > * Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> > > Implemented support for the whole RAM block memory
> > > protection/un-protection. Introduced higher level
> > >
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> On 25.11.2020 16:08, Dr. David Alan Gilbert wrote:
> > * Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> > > In this particular implementation the same single migration
> > > thread is responsible for both normal linear dirty page
> >
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
On 20-11-17 14:09:14, Jonathan Cameron wrote:
[snip]
>
> Agreed, it was the intermediate state that I wasn't keen on of structures
> defined
> but then given 0 size. I'd rather just look at them all once. If that
> sometimes
> means introducing a file that isn't even referenced for a few
On 25/11/2020 18.50, Paolo Bonzini wrote:
> Setuptools is not needed anymore by the bundled copy of meson,
> remove it.
>
> Suggested-by: Thomas Huth
> Signed-off-by: Paolo Bonzini
> ---
> .cirrus.yml| 1 -
> tests/docker/dockerfiles/debian10.docker
Hi Steven, Catalin,
On 18/11/2020 16:01, Steven Price wrote:
> On 17/11/2020 16:07, Catalin Marinas wrote:
>> On Mon, Oct 26, 2020 at 03:57:27PM +, Steven Price wrote:
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 19aacc7d64de..38fe25310ca1 100644
>>> ---
On 25/11/20 05:19, Thomas Huth wrote:
On 24/11/2020 22.19, Olaf Hering wrote:
Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not
required anymore.
That commit was part of meson 0.55.1. We require at least meson 0.55.3. So
right, this should be fine.
Signed-off-by:
Setuptools is not needed anymore by the bundled copy of meson,
remove it.
Suggested-by: Thomas Huth
Signed-off-by: Paolo Bonzini
---
.cirrus.yml| 1 -
tests/docker/dockerfiles/debian10.docker | 1 -
On 11/25/20 6:02 PM, Alex Bennée wrote:
>
> Claudio Fontana writes:
>
>> Hi Alex,
>>
>> On 11/25/20 10:42 AM, Alex Bennée wrote:
>>>
>>> Philippe Mathieu-Daudé writes:
>>>
On 11/24/20 12:04 PM, Claudio Fontana wrote:
> Hi Alex,
>
> I am seeing build failures with build-user
Claudio Fontana writes:
> Hi Alex,
>
> On 11/25/20 10:42 AM, Alex Bennée wrote:
>>
>> Philippe Mathieu-Daudé writes:
>>
>>> On 11/24/20 12:04 PM, Claudio Fontana wrote:
Hi Alex,
I am seeing build failures with build-user and build-user-plugin:
On 20-11-13 08:47:59, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 11/10/20 11:47 PM, Ben Widawsky wrote:
> >> A CXL memory device (AKA Type 3) is a CXL component that contains some
> >> combination of volatile and persistent memory. It also implements the
> >> previously defined
On Tue 24 Nov 2020 08:44:00 PM CET, Maxim Levitsky wrote:
> On Tue, 2020-11-24 at 20:59 +0200, Maxim Levitsky wrote:
>> On Tue, 2020-11-24 at 19:59 +0100, Alberto Garcia wrote:
>> > On Tue 24 Nov 2020 10:17:23 AM CET, Kevin Wolf wrote:
>> > > We can then continue work to find a minimal reproducer
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1779447
Title:
SLIRP SMB silently fails with MacOS smbd
Status in QEMU:
New
Bug description:
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
On 25.11.20 17:11, Jonathan Cameron wrote:
> On Wed, 25 Nov 2020 16:54:53 +0100
> David Hildenbrand wrote:
>
>>
>> 64k guest on 4k host with 512MiB block size seems fine.
>>
>> If there are any places anyone thinks need particular poking I'd
>> appreciate a hint :)
>
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1826568
Title:
RISC-V Disassembler/translator instruction decoding disagreement
Status in QEMU:
Closing according to comment #3
** 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.
https://bugs.launchpad.net/bugs/1837049
Title:
qemu-system-ppc segfaults with -display sdl
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
Hi! Did you ever get a backtrace? ... otherwise I think we have to close
this ticket due to insufficient data...
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On Wed, 25 Nov 2020 16:54:53 +0100
David Hildenbrand wrote:
>
> 64k guest on 4k host with 512MiB block size seems fine.
>
> If there are any places anyone thinks need particular poking I'd
> appreciate a hint :)
> >>>
> >>> If things seem to work for now, that's
On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > Hello,
> >
> > We recently found out that some softwares are effectively crashing
> > when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
>
Hi Cornelia,
On 11/25/20 4:03 PM, Thomas Huth wrote:
> On 25/11/2020 14.58, Cornelia Huck wrote:
>> This adds a very basic test for checking that we present devices
>> in a way that Linux can consume: boot with both virtio-net-ccw and
>> virtio-net-pci attached and then verify that Linux is able
64k guest on 4k host with 512MiB block size seems fine.
If there are any places anyone thinks need particular poking I'd
appreciate a hint :)
>>>
>>> If things seem to work for now, that's great :) Thanks!
>>>
>> Cool. I'll run a few more comprehensive tests then send
On Wed, 25 Nov 2020 16:03:13 +0100
Thomas Huth wrote:
> On 25/11/2020 14.58, Cornelia Huck wrote:
> > This adds a very basic test for checking that we present devices
> > in a way that Linux can consume: boot with both virtio-net-ccw and
> > virtio-net-pci attached and then verify that Linux is
Hi
On Mon, Sep 28, 2020 at 5:49 PM Peter Maydell
wrote:
> On Mon, 28 Sep 2020 at 14:12, Philippe Mathieu-Daudé
> wrote:
> >
> > Since commit efc6c070aca ("configure: Add a test for the
> > minimum compiler version") the minimum compiler version
> > required for GCC is 4.8, which has the GCC
> Ah. I'd missed that quirk around MAX_ORDER. It's also true of ARM64 with
> 4k pages. As you can probably guess I'd forgotten to recompile my 4k test
> kernel after adding that particular check. :(
>
> Ah well. Given we are already in a situation where adding 2MiB doesn't
> actually
> do
On 25/11/2020 14.58, Cornelia Huck wrote:
> This adds a very basic test for checking that we present devices
> in a way that Linux can consume: boot with both virtio-net-ccw and
> virtio-net-pci attached and then verify that Linux is able to see
> and detect these devices.
Thanks for tackling it!
On Wed, Nov 25, 2020 at 07:40:48AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Tue, Nov 24, 2020 at 04:20:37PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Tue, Nov 24, 2020 at 09:49:30AM +0100, Markus Armbruster wrote:
> >> >> Eduardo
On Tue, 24 Nov 2020 20:17:35 +0100
David Hildenbrand wrote:
> On 24.11.20 19:11, Jonathan Cameron wrote:
> > On Mon, 9 Nov 2020 20:47:09 +0100
> > David Hildenbrand wrote:
> >
> > +CC Eric based on similar query in other branch of the thread.
> >
> >> On 05.11.20 18:43, Jonathan Cameron
On Wed, Nov 25, 2020 at 12:48:22PM +0100, Claudio Fontana wrote:
> On 11/25/20 10:32 AM, Claudio Fontana wrote:
> > On 11/24/20 9:34 PM, Eduardo Habkost wrote:
> >> On Tue, Nov 24, 2020 at 08:39:33PM +0100, Claudio Fontana wrote:
> >>> On 11/24/20 8:27 PM, Eduardo Habkost wrote:
> On Tue, Nov
On Wednesday, 2020-11-25 at 18:18:56 +0530, P J P wrote:
> Hello Darren, all
>
> +-- On Tue, 24 Nov 2020, Darren Kenny wrote --+
> | I always understood triage to be the initial steps in assessing a bug:
> |
> | - determining if it is a security bug, in this case
> | - then deciding on the
1 - 100 of 169 matches
Mail list logo
