On Mon, Oct 28, 2019 at 7:08 PM Kyle Evans wrote:
>
> Hi,
>
> We're working on improving bsd-user in a local tree and rebasing forward
> to get our work suitable for upstreaming. I'm porting the safe_syscall stuff
> over to bsd-user, and would like to get some design guidance as it may best
> be i
On 12/5/19 10:40 AM, Peter Maydell wrote:
>> + * If it is, we must allocate the ram to back that up.
>> + */
>> +if (object_property_find(cpuobj, "tag-memory", NULL)) {
>> +if (!tag_sysmem) {
>> +tag_sysmem = g_new(MemoryRegion, 1);
>> +
Here is double bug:
First, return error but not set errp. This may lead to:
qmp block-dirty-bitmap-remove may report success when actually failed
block-dirty-bitmap-remove used in a transaction will crash, as
qmp_transaction will think that it returned success and will cal
block_dirty_bitmap_remo
On 12/05/19 17:50, Ard Biesheuvel wrote:
> On Thu, 5 Dec 2019 at 16:27, Philippe Mathieu-Daudé wrote:
>>
>> On 12/5/19 5:13 PM, Laszlo Ersek wrote:
>>> Hi Phil,
>>>
>>> (+Ard)
>>>
>>> On 12/04/19 23:12, Philippe Mathieu-Daudé wrote:
Centos 7.7 only provides cross GCC 4.8.5, but the script for
On 12/5/19 9:31 AM, Alex Bennée wrote:
>
> Richard Henderson writes:
>
>> On 11/30/19 8:45 AM, Alex Bennée wrote:
>>> The Linux kernel chooses the default of 64 bytes for SVE registers on
>>> the basis that it is the largest size that won't grow the signal
>>> frame. When debugging larger sizes
On 12/5/19 2:30 PM, Vladimir Sementsov-Ogievskiy wrote:
> Here is double bug:
>
> First, return error but not set errp. This may lead to:
> qmp block-dirty-bitmap-remove may report success when actually failed
>
> block-dirty-bitmap-remove used in a transaction will crash, as
> qmp_transaction
Ok, understood.
On Thu, Dec 5, 2019 at 8:45 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Tuesday, October 29, 2019, Michael Rolnik wrote:
>
>> From: Sarah Harris
>>
>> These were designed to facilitate testing but should provide enough
>> function to be useful in other
On 12/5/19 12:09 PM, Vladimir Sementsov-Ogievskiy wrote:
All callers of nbd_iter_channel_error() pass the address of a local_err
variable, and only call this function if an error has already occurred, using
this function
to append details to that error.
Hmm, not to append details but to
On 12/5/19 1:30 PM, Vladimir Sementsov-Ogievskiy wrote:
Here is double bug:
First, return error but not set errp. This may lead to:
qmp block-dirty-bitmap-remove may report success when actually failed
block-dirty-bitmap-remove used in a transaction will crash, as
qmp_transaction will think tha
On 12/05/19 19:17, Ard Biesheuvel wrote:
> On Thu, 5 Dec 2019 at 18:09, Philippe Mathieu-Daudé wrote:
>>
>> The Debian (based) distributions historically provides 2 ARM
>> toolchains, documented as [1]:
>>
>> * The ARM EABI (armel) port targets a range of older 32-bit ARM
>> devices, particularl
On 12/5/19 3:09 PM, Eric Blake wrote:
> On 12/5/19 1:30 PM, Vladimir Sementsov-Ogievskiy wrote:
>> Here is double bug:
>>
>> First, return error but not set errp. This may lead to:
>> qmp block-dirty-bitmap-remove may report success when actually failed
>>
>> block-dirty-bitmap-remove used in a
On Wed, Dec 04, 2019 at 04:46:15PM +0100, Thomas Huth wrote:
> In certain environments like restricted containers, we can not create
> huge test images. To be able to use "make check" in such container
> environments, too, let's skip the hd-geo-test instead of failing when
> the test images could n
Devices "ivshmem-plain" and "ivshmem-doorbell" support only MSI-X.
Config space register Interrupt Pin is zero. Device "ivshmem"
additionally supported legacy INTx, but it was removed in commit
5a0e75f0a9 "hw/misc/ivshmem: Remove deprecated "ivshmem" legacy
device". The commit left ivshmem_update
On Wed, Dec 04, 2019 at 04:46:16PM +0100, Thomas Huth wrote:
> test-util-filemonitor fails in restricted non-x86 Travis containers
> since they apparently blacklisted some required system calls there.
> Let's simply skip the test if we detect such an environment.
>
> Reviewed-by: Philippe Mathieu-
On 12/4/19 3:39 PM, Philippe Mathieu-Daudé wrote:
> Commit 34ea023d4b9 introduced the Tulip PCI NIC.
> Since this better models the DP264 hardware, use it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/alpha/dp264.c | 4 ++--
> hw/alpha/Kconfig | 2 +-
> 2 files changed, 3 insertions(+),
On Wed, Dec 04, 2019 at 04:46:17PM +0100, Thomas Huth wrote:
> From: Alex Bennée
>
> Our docker infrastructure isn't quite as multiarch as we would wish so
> let's allow the user to disable it if they want. This will allow us to
> use still run check-tcg on non-x86 CI setups.
>
> Signed-off-by:
On Wed, Nov 27, 2019 at 09:42:50AM +0100, Geert Uytterhoeven wrote:
> Add Device Tree bindings for a GPIO repeater, with optional translation
> of physical signal properties. This is useful for describing explicitly
> the presence of e.g. an inverter on a GPIO line, and was inspired by the
> non-Y
On Mon, Dec 02, 2019 at 05:49:58PM -0300, Eduardo Habkost wrote:
> On Sun, Dec 01, 2019 at 12:46:12AM +0100, Aleksandar Markovic wrote:
> > On Monday, November 25, 2019, Filip Bozuta wrote:
> >
> > > The script checkpatch.pl located in scripts folder was
> > > used to detect all errors and warrni
On 05.12.19 12:14, Markus Armbruster wrote:
> This has been on the list for more than three weeks already. I
> apologize for the delay.
No problem! Your feedback is highly appreciated.
>
> Jan Kiszka writes:
>
>> From: Jan Kiszka
>>
>> This imports the ivshmem v2 specification draft from Jai
On 12/5/19 2:16 PM, John Snow wrote:
Last minute edit: hmm, actually, transaction action introduced in
4.2, so crash is not a regression, only broken block-dirty-bitmap-remove
command is a regression... Maybe it's OK for stable.
Libvirt REALLY wants to use transaction bitmap management (and re
On 12/5/19 4:53 PM, Eric Blake wrote:
> On 12/5/19 2:16 PM, John Snow wrote:
>
Last minute edit: hmm, actually, transaction action introduced in
4.2, so crash is not a regression, only broken
block-dirty-bitmap-remove
command is a regression... Maybe it's OK for stable.
>>>
On 12/5/19 10:06 AM, Thomas Huth wrote:
They can't be used reliable for live-migration anymore (see
https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html
for details) and have been marked as deprecated since QEMU v4.0,
so time to remove them now.
And while we're at it, mark the rem
Hello Eric,
On 05/12/2019 09:42, Auger Eric wrote:
> Not related to this patch but I noticed SMMU_BASE_ADDR_MASK should be
> 0xffc0 and not 0xffe0. I can fix it separately or if you
> respin, you may fix it as well?
Good catch, thank you. I'll fix it in the next version.
Looking
Hello Philippe,
On Tue, Dec 3, 2019 at 10:18 AM Philippe Mathieu-Daudé
wrote:
> On 12/2/19 10:09 PM, Niek Linnenbank wrote:
> > The Xunlong Orange Pi PC is an Allwinner H3 System on Chip
> > based embedded computer with mainline support in both U-Boot
> > and Linux. The board comes with a Quad C
When using `query-cpu-definitions` using `-machine none`,
QEMU is resolving all CPU models to their latest versions. The
actual CPU model version being used by another machine type (e.g.
`pc-q35-4.0`) might be different.
In theory, this was OK because the correct CPU model
version is returned whe
This has come up in the past, and I believe we discussed this at KVM
Forum, too:
There have been requests from oVirt (via Nir Soffer) to add some offline
bitmap manipulation functionality. In the past, our stance has generally
been "Use QEMU without an accelerator, and use QMP to manipulate the
im
On Wed, 4 Dec 2019 22:26:38 -0500
Yan Zhao wrote:
> Vendor driver specifies when to support a migration region through cap
> VFIO_PCI_DEVICE_CAP_MIGRATION in vfio_pci_mediate_ops->open().
>
> If vfio-pci detects this cap, it creates a default migration region on
> behalf of vendor driver with r
On Wed, 4 Dec 2019 22:25:36 -0500
Yan Zhao wrote:
> when vfio-pci is bound to a physical device, almost all the hardware
> resources are passthroughed.
> Sometimes, vendor driver of this physcial device may want to mediate some
> hardware resource access for a short period of time, e.g. dirty pa
On Wed, 4 Dec 2019 22:26:50 -0500
Yan Zhao wrote:
> Dynamic trap bar info region is a channel for QEMU and vendor driver to
> communicate dynamic trap info. It is of type
> VFIO_REGION_TYPE_DYNAMIC_TRAP_BAR_INFO and subtype
> VFIO_REGION_SUBTYPE_DYNAMIC_TRAP_BAR_INFO.
>
> This region has two fi
On 12/05/19 20:00, Philippe Mathieu-Daudé wrote:
> The Debian (based) distributions currently provides 2 ARM
> toolchains, documented as [1]:
>
> * The ARM EABI (armel) port targets a range of older 32-bit ARM
> devices, particularly those used in NAS hardware and a variety
> of *plug computer
On Thu, Dec 05, 2019 at 06:20:05PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Make kvmppc_hint_smt_possible hint append helper well formed:
> rename errp to errp_in, as it is IN-parameter here (which is unusual
> for errp), rename function to be kvmppc_error_append_*_hint.
>
> Signed-off-by: Vla
On Thu, Dec 05, 2019 at 08:46:21PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Make kvmppc_hint_smt_possible hint append helper well formed:
> switch errp paramter to Error *const * type, as it has uncommon
> behavior: not change the pointer to return error, but operate on
> already existent error
The following changes since commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e:
Update version for v4.2.0-rc4 release (2019-12-03 17:56:30 +)
are available in the Git repository at:
g...@github.com:aik/qemu.git tags/qemu-slof-20191206
for you to fetch changes up to e53a5569a27066a4f2f36ae3
On Thu, Dec 05, 2019 at 10:39:29AM +0530, Ganesh wrote:
>
> On 11/19/19 8:15 AM, David Gibson wrote:
> > On Thu, Oct 24, 2019 at 01:13:06PM +0530, Ganesh Goudar wrote:
> > > From: Aravinda Prasad
> > >
> > > This patch includes migration support for machine check
> > > handling. Especially this
On 2019/12/6 0:45, Amit Shah wrote:
> On Wed, 2019-12-04 at 15:31 +0800, pannengy...@huawei.com wrote:
>> From: Pan Nengyuan
>
> Shouldn't this be From: mst?
>
> I didn't find a ref to the original patch to confirm if you had to
> adapt it in any way, though.
>
Here is the original
patch: ht
qemu sparc64 also failed to boot Oracle Linux
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1670175
Title:
qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic -
kernel: no nucleus h
On Fri, Dec 06, 2019 at 12:25:29PM +1100, Alexey Kardashevskiy wrote:
> The following changes since commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e:
>
> Update version for v4.2.0-rc4 release (2019-12-03 17:56:30 +)
>
> are available in the Git repository at:
>
> g...@github.com:aik/qemu.
On Wed, Nov 27, 2019 at 09:50:54AM +0530, Bharata B Rao wrote:
> On Fri, Nov 22, 2019 at 10:42 AM David Gibson
> wrote:
> >
> > Ok. A number of queries about this.
> >
> > 1) The PAPR spec for ibm,dynamic-memory-v2 says that the first word in
> > each entry is the number of LMBs, but for NVDIMMs
The following changes since commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e:
Update version for v4.2.0-rc4 release (2019-12-03 17:56:30 +)
are available in the Git repository at:
git://github.com/dgibson/qemu.git tags/ppc-for-4.2-20191206
for you to fetch changes up to d887a8cfc083bcf38
On 05/12/2019 21.35, Markus Armbruster wrote:
> Devices "ivshmem-plain" and "ivshmem-doorbell" support only MSI-X.
> Config space register Interrupt Pin is zero. Device "ivshmem"
> additionally supported legacy INTx, but it was removed in commit
> 5a0e75f0a9 "hw/misc/ivshmem: Remove deprecated "iv
On 05/12/2019 23.00, Eric Blake wrote:
> On 12/5/19 10:06 AM, Thomas Huth wrote:
>> They can't be used reliable for live-migration anymore (see
>> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html
>> for details) and have been marked as deprecated since QEMU v4.0,
>> so time to re
On 12/5/19 8:35 PM, Laszlo Ersek wrote:
On 12/05/19 17:50, Ard Biesheuvel wrote:
On Thu, 5 Dec 2019 at 16:27, Philippe Mathieu-Daudé wrote:
On 12/5/19 5:13 PM, Laszlo Ersek wrote:
Hi Phil,
(+Ard)
On 12/04/19 23:12, Philippe Mathieu-Daudé wrote:
Centos 7.7 only provides cross GCC 4.8.5, bu
On 12/5/19 8:56 PM, Laszlo Ersek wrote:
On 12/05/19 19:17, Ard Biesheuvel wrote:
On Thu, 5 Dec 2019 at 18:09, Philippe Mathieu-Daudé wrote:
The Debian (based) distributions historically provides 2 ARM
toolchains, documented as [1]:
* The ARM EABI (armel) port targets a range of older 32-bit
On 11/29/19 1:36 PM, Philippe Mathieu-Daudé wrote:
On Fri, Nov 29, 2019 at 1:10 PM Laszlo Ersek wrote:
On 11/29/19 11:44, Philippe Mathieu-Daudé wrote:
I had this commit ready for when the next EDK2 release were go out,
which just happened: https://edk2.groups.io/g/devel/message/51502
Laszlo
On 12/6/19 1:19 AM, Laszlo Ersek wrote:
On 12/05/19 20:00, Philippe Mathieu-Daudé wrote:
The Debian (based) distributions currently provides 2 ARM
toolchains, documented as [1]:
* The ARM EABI (armel) port targets a range of older 32-bit ARM
devices, particularly those used in NAS hardware a
Now that the "name" parameter is gone, there is hardly any difference
between NetLegacy and Netdev anymore. Drop NetLegacy and always use
Netdev to simplify the code quite a bit.
Signed-off-by: Thomas Huth
---
net/net.c | 74 ---
qapi/net.json
It's been deprecated since QEMU v3.1, so it's time to finally
remove it. The "id" parameter can simply be used instead.
Signed-off-by: Thomas Huth
---
net/net.c| 10 +-
qapi/net.json| 4 +---
qemu-deprecated.texi | 12 +++-
3 files changed, 9 insertions(+), 1
It's time to remove the deprecated "name" parameter from -net.
Please have a closer look at the second patch ... I think it should be
fine, but I'm not 100% sure whether it's ok for all cases to drop NetLegacy,
so please double-check.
Thomas Huth (2):
net: Drop the legacy "name" parameter from
On 12/5/19 11:15 PM, Niek Linnenbank wrote:
Hello Philippe,
On Tue, Dec 3, 2019 at 10:18 AM Philippe Mathieu-Daudé
mailto:phi...@redhat.com>> wrote:
On 12/2/19 10:09 PM, Niek Linnenbank wrote:
> The Xunlong Orange Pi PC is an Allwinner H3 System on Chip
> based embedded computer
201 - 249 of 249 matches
Mail list logo
