David Carlier (3):
configure: fix for SunOS based systems.
exec: posix_madvise usage on SunOS.
contrib: ivshmem client and server build fix for SunOS.
configure | 2 +-
contrib/ivshmem-client/ivshmem-client.c | 12 ++--
contrib/ivshmem-server/ivshmem-s
Hello,
Ottavio Caruso, le mar. 14 juil. 2020 12:15:48 +0100, a ecrit:
> I cannot get traceroute to work with standard udp from any of my
> guests.
>
> $ traceroute 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
> 1 * * *
That was because
- libslirp was not forwarding
On 2020/7/14 上午2:46, Laurent Vivier wrote:
>> +gparam->value = lock_user(VERIFY_WRITE, target_gparam->value,
>> + sizeof(*gparam->value), 0);
>
> I don't think you should use directly the guest memory.
> You should have something like that:
>
> int value;
>
>
On Fri, 17 Jul 2020 at 16:17, Eric Blake wrote:
>
> The following changes since commit 151f76c689b1ff4c2c59e6d8469a0d4fe5346f55:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request'
> into staging (2020-07-16 21:46:18 +0100)
>
> are available in the Git repository at:
On Mon, Jul 13, 2020 at 21:04:10 +0100, Alex Bennée wrote:
> Any write to a device might cause a re-arrangement of memory
> triggering a TLB flush and potential re-size of the TLB invalidating
> previous entries. This would cause users of qemu_plugin_get_hwaddr()
> to see the warning:
>
> invali
On 7/17/20 5:49 PM, Jessica Clarke wrote:
> The specification says:
>
>0x00 TIME_LOW R: Get current time, then return low-order 32-bits.
>0x04 TIME_HIGH R: Return high 32-bits from previous TIME_LOW read.
>
>...
>
>To read the value, the kernel must perform an IO_READ(TIME_L
On Fri, 17 Jul 2020 at 14:56, Cornelia Huck wrote:
>
> The following changes since commit 151f76c689b1ff4c2c59e6d8469a0d4fe5346f55:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request'
> into staging (2020-07-16 21:46:18 +0100)
>
> are available in the Git repository a
Hi David,
Your git-sendemail seems broken... Usually 0/N is for the cover
letter, patches are 1/N to N/N. Also patches are sent as replies
to the cover (as a thread). In your series all patches are posted
as new thread...
On 7/18/20 3:19 PM, David CARLIER wrote:
> From 63a3c9639d708a796abd958607a
On Sat, 18 Jul 2020 at 15:45, Jessica Clarke wrote:
> On 18 Jul 2020, at 08:42, Philippe Mathieu-Daudé wrote:
> > Maybe easier to cache the whole u64, this matches RTC_ALARM_LOW /
> > RTC_ALARM_HIGH pattern (goldfish_rtc_vmstate change not included):
>
> We could, but why waste space storing an e
> -Original Message-
> From: Roman Bolshakov
> Sent: Friday, July 17, 2020 5:35 PM
> To: qemu-devel@nongnu.org
> Cc: Daniel P. Berrangé ; Stefan Hajnoczi
> ; Cameron Esfahani ; Roman
> Bolshakov ; Philippe Mathieu-Daudé
> ; Zhang, Chen ; Li Zhijian
> ; Jason Wang
> Subject: [PATCH v2 4/
On Fri, 17 Jul 2020 at 13:55, Kevin Wolf wrote:
>
> The following changes since commit 151f76c689b1ff4c2c59e6d8469a0d4fe5346f55:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request'
> into staging (2020-07-16 21:46:18 +0100)
>
> are available in the Git repository at:
It probably does not indeed (maybe Solaris madvise does not provide
but memcntl ?), I was just trying to fix the build only :-)
On Sat, 18 Jul 2020 at 15:15, Peter Maydell wrote:
>
> On Sat, 18 Jul 2020 at 14:21, David CARLIER wrote:
> >
> > From a9e3cced279ae55a59847ba232f7828bc2479367 Mon Sep
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
** Changed in: qemu
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1213196
Title:
-serial tcp should hang up when DTR goes low
Status in QEMU:
New
Bug descri
I ran this through my minimization script to remove the extraneous qtest
commands:
cat << EOF | ./i386-softmmu/qemu-system-i386 \
-M pc-q35-5.0 -no-shutdown -M q35 -device megasas \
-device scsi-cd,drive=null0 \
-blockdev driver=null-co,read-zeroes=on,node-name=null0 \
-nographic -qtest stdio -mon
Seems like you have to set all to "incomplete" to restart the expire
counter again...
** Changed in: ubuntu-z-systems
Status: Expired => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bug
On 18 Jul 2020, at 08:42, Philippe Mathieu-Daudé wrote:
> On 7/18/20 2:49 AM, Jessica Clarke wrote:
>> The specification says:
>>
>> 0x00 TIME_LOW R: Get current time, then return low-order 32-bits.
>> 0x04 TIME_HIGH R: Return high 32-bits from previous TIME_LOW read.
>>
>> ...
>>
>>
** Changed in: qemu
Assignee: John Snow (jnsnow) => (unassigned)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1816805
Title:
Cannot create cdrom device with open tray and cache option
Status
** Project changed: qemu => qemu (Ubuntu)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
Status in MAAS:
Triaged
Statu
On 18/07/2020 09.09, Pratik Parvati wrote:
> Hi team,
>
> Could someone please guild me to understand the difference
> between *instance_init()* and the*realize()* functions? The
> *class_init() *function is straight forward (it is similar to the
> constructor in C++ OOP); But I am, finding hard t
On Sat, 18 Jul 2020 at 14:22, David CARLIER wrote:
>
> From 1c5225132a01ad67c87d603659ef4e4bcd46a16d Mon Sep 17 00:00:00 2001
> From: David Carlier
> Date: Sat, 18 Jul 2020 13:32:47 +0100
> Subject: [PATCH 3/3] contrib: ivshmem client and server build fix for SunOS.
>
> sun is a macro on these sy
On Sat, 18 Jul 2020 at 14:21, David CARLIER wrote:
>
> From a9e3cced279ae55a59847ba232f7828bc2479367 Mon Sep 17 00:00:00 2001
> From: David Carlier
> Date: Sat, 18 Jul 2020 13:29:44 +0100
> Subject: [PATCH 2/3] exec: posix_madvise usage on SunOS.
>
> with _XOPEN_SOURCE set, the older mman.h API b
On Fri, 17 Jul 2020 at 18:24, John Snow wrote:
>
> - The real problem, though: Why is QEMU hanging? It might need a longer
> timeout, or it might be having problems with the console socket again.
>
> (CC Robert Foley who has been working on the Console socket draining
> problems. Maybe he has some
>From 1c5225132a01ad67c87d603659ef4e4bcd46a16d Mon Sep 17 00:00:00 2001
From: David Carlier
Date: Sat, 18 Jul 2020 13:32:47 +0100
Subject: [PATCH 3/3] contrib: ivshmem client and server build fix for SunOS.
sun is a macro on these systems, thus renaming the variables on the
client and server.
S
>From a9e3cced279ae55a59847ba232f7828bc2479367 Mon Sep 17 00:00:00 2001
From: David Carlier
Date: Sat, 18 Jul 2020 13:29:44 +0100
Subject: [PATCH 2/3] exec: posix_madvise usage on SunOS.
with _XOPEN_SOURCE set, the older mman.h API based on caddr_t handling
is not accessible thus using posix_madv
>From 63a3c9639d708a796abd958607aa6376fc9b99f2 Mon Sep 17 00:00:00 2001
From: David Carlier
Date: Sat, 18 Jul 2020 13:27:52 +0100
Subject: [PATCH 1/3] configure: fix for SunOS based systems.
local directive make the configure fails on these systems.
Signed-off-by: David Carlier
---
configure |
>From 1c5225132a01ad67c87d603659ef4e4bcd46a16d Mon Sep 17 00:00:00 2001
From: David Carlier
Date: Sat, 18 Jul 2020 13:33:47 +0100
Subject: [PATCH 0/3] build: fix for SunOS systems.
David Carlier (3):
configure: fix for SunOS based systems.
exec: posix_madvise usage on SunOS.
contrib: ivshme
** Tags added: linux-user
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880287
Title:
gcc crashes in hppa emulation
Status in QEMU:
New
Bug description:
There seems to be a translation bug i
Cc'ing Hannes who doesn't have a Launchpad account.
On 7/18/20 12:24 PM, Philippe Mathieu-Daudé wrote:
> Might be relevant:
>
> commit 6df5718bd3ec56225c44cf96440c723c1b611b87
> Author: Hannes Reinecke
> Date: Wed Oct 29 13:00:15 2014 +0100
>
> megasas: Rework frame queueing algorithm
>
Might be relevant:
commit 6df5718bd3ec56225c44cf96440c723c1b611b87
Author: Hannes Reinecke
Date: Wed Oct 29 13:00:15 2014 +0100
megasas: Rework frame queueing algorithm
Windows requires the frames to be unmapped, otherwise we run
into a race condition where the updated frame d
> On 18 Jul 2020, at 12:43, Peter Maydell wrote:
>
> Note that for a lot
> of device state struct members (where they correspond to guest
> registers state), you want to set their values in the
> device's reset method, not in instance_init or realize.
> That's because the guest-visible registe
Fixed in commit 77f55eac6c433e23e82a1b88b2d74f385c4c7d82.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878259
Title:
Null-pointer derefere
On Sat, 18 Jul 2020 at 09:27, Liviu Ionescu wrote:
> For me it was difficult to draw a line of what initialisations should be done
> in .instance_init and what in .realize, but given that .realise is called
> when the whole hierarchy is ready, it might do links between objects, which
> are not
The last microcode word (address 0x6000.6ffc) is not reachable.
Correct the programmable FPU I/O size (which is 4 KiB) to be
able to use all the microcode area.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/misc/milkymist-pfpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
On Fri, 17 Jul 2020 at 23:24, John Snow wrote:
> - The real problem, though: Why is QEMU hanging? It might need a longer
> timeout, or it might be having problems with the console socket again.
The host machine seemed to be under really heavy I/O load at the time.
thanks
-- PMM
> On 18 Jul 2020, at 10:09, Pratik Parvati wrote:
>
> The class_init() function is straight forward (it is similar to the
> constructor in C++ OOP
The C++ constructor initialises class **instances**, i.e. C++ objects, not C++
classes.
In QEMU, the OOP functionality is implemented with nest
Proposed fix:
https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05637.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1884693
Title:
Assertion failure in address_space_unmap through ahci_
On 7/18/20 2:49 AM, Jessica Clarke wrote:
> The specification says:
>
>0x00 TIME_LOW R: Get current time, then return low-order 32-bits.
>0x04 TIME_HIGH R: Return high 32-bits from previous TIME_LOW read.
>
>...
>
>To read the value, the kernel must perform an IO_READ(TIME_L
libFuzzer triggered the following assertion:
cat << EOF | qemu-system-i386 -M pc-q35-5.0 \
-nographic -monitor none -serial none -qtest stdio
outl 0xcf8 0x8000fa24
outl 0xcfc 0xe1068000
outl 0xcf8 0x8000fa04
outw 0xcfc 0x7
outl 0xcf8 0x8000fb20
write 0xe1068304 0x1 0x21
write 0
Hi team,
Could someone please guild me to understand the difference between
*instance_init()* and the* realize()* functions? The *class_init() *function
is straight forward (it is similar to the constructor in C++ OOP); But I
am, finding hard to quote the difference between *instance_init()* and
*
41 matches
Mail list logo
