This bug was fixed in the package qemu - 1:5.0-5ubuntu3
---
qemu (1:5.0-5ubuntu3) groovy; urgency=medium
* d/p/ubuntu/lp-1887763-*: fix TCG sizing that OOMed many small CI
environments (LP: #1887763)
* Pick further changes for groovy from debian/master since 5.0-5
- ati-vg
After reading through some of the code for the e1000, e1000e, and
vmxnet3 device models, it appears that all 3 are capable of performing
tcp segementation, however, in the net_tx_pkt_send function, there is a
check
if (pkt->has_virt_hdr ||
pkt->virt_hdr.gso_type == VIRTIO_NET_HDR_GSO_NONE)
> Hi Justin, Sunil,
Justin has moved to a different team is no longer working with WHPX. Moving him
to bcc.
>
> On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote:
> > +launchpad ticket
> >
> > On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
> >> Hey Phil,
> >>
> >> I have contacted our legal depart
On Thu, Jul 30, 2020 at 12:38 PM Daniel P. Berrangé wrote:
>
> On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote:
> > Andrea Bolognani writes:
> >
> > > The various schemas included in QEMU use a JSON-based format which
> > > is, however, strictly speaking not valid JSON.
> > >
>
I just pushed/uploaded a SRU for bionic from:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/387269
Waiting for SRU on it.
** Changed in: qemu (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notificati
On 7/31/20 1:34 PM, Eduardo Habkost wrote:
> On Mon, Jun 01, 2020 at 08:19:51AM +0200, Philippe Mathieu-Daudé wrote:
>> Hi Robert.
>>
>> Top-posting is difficult to read on technical lists,
>> it's better to reply inline.
>>
>> Cc'ing the X86 FPU maintainers:
>>
>> ./scripts/get_maintainer.pl -f t
Public bug reported:
Bug in QEMU 5.0.0:
virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded.
If iommu_platform is disabled the guest immediately locks up as a result of the
configured PCIe-Passthrough.
Host system:
- Arch Linux amd64
- AMD Ryzen Platform
- QEMU 5.0.0
Public bug reported:
Problem Description:
When using a tap interface and the guest sends a TCP packet that would need to
be segmented, it is fragmented using IP fragmentation. The host does not
reassemble the IP fragments and forwards them to the next hop. This causes
issues on certain ISPs, wh
On Wed, Jun 03, 2020 at 07:04:26AM +0200, Philippe Mathieu-Daudé wrote:
> On 5/5/20 4:28 PM, Philippe Mathieu-Daudé wrote:
> > Drop superfluous parenthesis around VMPortReadFunc typedef
> > (added in d67f679d99, missed to remove when moved in e595112985).
> >
> > Suggested-by: Richard Henderson
On Mon, Jun 01, 2020 at 08:19:51AM +0200, Philippe Mathieu-Daudé wrote:
> Hi Robert.
>
> Top-posting is difficult to read on technical lists,
> it's better to reply inline.
>
> Cc'ing the X86 FPU maintainers:
>
> ./scripts/get_maintainer.pl -f target/i386/fpu_helper.c
> Paolo Bonzini (maintain
Yes, that is correct. It's more work but also more maintainable.
Thanks,
Paolo
Il ven 31 lug 2020, 22:09 Robert Foley ha scritto:
> On Fri, 31 Jul 2020 at 14:02, Paolo Bonzini wrote:
> >
> > On 31/07/20 14:51, Robert Foley wrote:
> > > This change removes the implied BQL from the cpu_handle_i
On Fri, 31 Jul 2020 at 14:02, Paolo Bonzini wrote:
>
> On 31/07/20 14:51, Robert Foley wrote:
> > This change removes the implied BQL from the cpu_handle_interrupt,
> > and cpu_handle_exception paths. We can now select per-arch if
> > the BQL is needed or not by using the bql_interrupt flag.
> > B
On Fri, Jul 31, 2020 at 08:49:38PM +0200, Julia Suvorova wrote:
> This feature allows MMCONFIG to be used even to access the base PCI
> config space [1]. This means increased performance: one access to
> MMCONFIG instead of two conventional accesses to I/O ports.
>
> Q35 makes no distinction in ba
On Fri, Jul 31, 2020 at 03:14:02PM -0400, Robert Foley wrote:
> On Fri, 31 Jul 2020 at 13:44, Eduardo Habkost wrote:
> > >
> > > +static inline void cpu_class_disable_bql_interrupt(CPUClass *cc)
> > > +{
> > > +cc->bql_interrupt = false;
> > > +}
> >
> > Class data is not supposed to change ou
On 7/30/2020 5:39 PM, Paolo Bonzini wrote:
> On 30/07/20 21:09, Steven Sistare wrote:
>>> please spell it out. Also, how does the functionality compare to
>>> xen-save-devices-state and xen-load-devices-state?
>>
>> qmp_xen_save_devices_state serializes device state to a file which is loaded
>> o
On Fri, 31 Jul 2020 at 13:44, Eduardo Habkost wrote:
> >
> > +static inline void cpu_class_disable_bql_interrupt(CPUClass *cc)
> > +{
> > +cc->bql_interrupt = false;
> > +}
>
> Class data is not supposed to change outside class_init. Why do
> you need this function? I don't see it being used
Syscall 'recvmmsg()' takes an argument which is of type 'struct timespec'
that represents a timeout for the receive operation. Before changes from
this patch, the timeout argument was ignored. This was probably due to
the way 'recvmmsg()' was implemented with looping over 'recvmsg()' which
doesn't
Implementations of 'sendmmsg()' and 'recvmmsg()' in 'syscall.c' use
a loop over a host command of 'sendmsg()' and 'recvmsg()' respectively
to send/receive individual messages from a socket. This patch changes
these implementations to use the host commands 'sendmmsg()' and 'recvmmsg()'
to send all m
This patch introduces functionality for syscall:
*recvmmsg_time64
This syscall is a 2038 safe variant for syscall:
int recvmmsg(int sockfd, struct mmsghdr *msgvec, unsigned int vlen,
int flags, struct timespec *timeout)
--receive multiple messages on a socket--
m
This patch introduces functionality for 'recvmmsg_time64()' which
is a year 2038 safe variant of 'recvmmsg()'. This new time64 syscall
is introduced in series of three patches rather than in one patch
because a little modification was needed before the syscall could
be introduced properly.
The fir
** Description changed:
+
+ SRU TEAM REVIEWER: This has already been SRUed for Focal, Eoan and Bionic.
Unfortunately the Bionic SRU did not work and we had to reverse the change.
Since then we had another update and now I'm retrying the SRU.
+
+ After discussing with @paelzer (and @dannf as a
This feature allows MMCONFIG to be used even to access the base PCI
config space [1]. This means increased performance: one access to
MMCONFIG instead of two conventional accesses to I/O ports.
Q35 makes no distinction in base or extended PCI config access to
MMCONFIG, MMCONFIG is always on, and i
SyncSysMemMsg message format is defined. It is used to send
file descriptors of the RAM regions to remote device.
RAM on the remote device is configured with a set of file descriptors.
Old RAM regions are deleted and new regions, each with an fd, is
added to the RAM.
Signed-off-by: Jagannathan Ram
From: Elena Ufimtseva
In order to detect remote processes which are hung, the
proxy periodically sends heartbeat messages to confirm if
the remote process is alive. The remote process responds
to this heartbeat message to confirm it is alive.
Signed-off-by: Jagannathan Raman
Signed-off-by: John
> On Jul 27, 2020, at 9:18 AM, Stefan Hajnoczi wrote:
>
> On Fri, Jul 24, 2020 at 12:57:22PM -0400, Jag Raman wrote:
>>> On Jul 1, 2020, at 5:20 AM, Stefan Hajnoczi wrote:
>>> On Sat, Jun 27, 2020 at 10:09:34AM -0700, elena.ufimts...@oracle.com wrote:
>>> In a 1:1 model the CONNECT_DEV messag
From: Elena Ufimtseva
The Proxy Object sends the PCI config space accesses as messages
to the remote process over the communication channel
TODO:
Investigate if the local PCI config writes can be dropped.
Without the proxy local PCI config space writes for the device,
the driver in the guest tim
From: John G Johnson
Signed-off-by: John G Johnson
Signed-off-by: Elena Ufimtseva
Signed-off-by: Jagannathan Raman
---
MAINTAINERS | 1 +
docs/devel/index.rst | 1 +
docs/devel/multi-process.rst | 966 +++
3 files changed, 9
From: Elena Ufimtseva
Defines MPQemuMsg, which is the message that is sent to the remote
process. This message is sent over QIOChannel and is used to
command the remote process to perform various tasks.
Also defined the helper functions to send and receive messages over the
QIOChannel
Signed-of
From: Elena Ufimtseva
Perform device reset in the remote process when QEMU performs
device reset. This is required to reset the internal state
(like registers, etc...) of emulated devices
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
---
hw/i38
IOHUB object is added to manage PCI IRQs. It uses KVM_IRQFD
ioctl to create irqfd to injecting PCI interrupts to the guest.
IOHUB object forwards the irqfd to the remote process. Remote process
uses this fd to directly send interrupts to the guest, bypassing QEMU.
Signed-off-by: John G Johnson
Si
Retrieve PCI configuration info about the remote device and
configure the Proxy PCI object based on the returned information
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
---
hw/pci/proxy.c | 85 +
From: Elena Ufimtseva
Signed-off-by: Elena Ufimtseva
Signed-off-by: Jagannathan Raman
Signed-off-by: John G Johnson
---
MAINTAINERS| 2 ++
docs/multi-process.rst | 67 ++
scripts/mpqemu-launcher.py | 49 +
Proxy device object implements handler for PCI BAR writes and reads.
The handler uses BAR_WRITE/BAR_READ message to communicate to the
remote process with the BAR address and value to be written/read.
The remote process implements handler for BAR_WRITE/BAR_READ
message.
Signed-off-by: Jagannathan
Associate the file descriptor for a PCIDevice in remote process with
DeviceState object.
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
---
MAINTAINERS | 2 +
hw/i386/Makefile.objs| 1 +
hw/i386/remote-obj.c |
Add memory-listener object which is used to keep the view of the RAM
in sync between QEMU and remote process.
A MemoryListener is registered for system-memory AddressSpace. The
listener sends SYNC_SYSMEM message to the remote process when memory
listener commits the changes to memory, the remote pr
From: Elena Ufimtseva
process to avoid blocking the main loop during the message exchanges.
To be used by proxy device.
Signed-off-by: Elena Ufimtseva
Signed-off-by: Jagannathan Raman
Signed-off-by: John G Johnson
---
include/io/mpqemu-link.h | 15 +
io/mpqemu-link.c | 82 +++
remote-machine object sets up various subsystems of the remote
device process. Instantiate PCI host bridge object and initialize RAM, IO &
PCI memory regions.
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
Signed-off-by: Elena Ufimtseva
---
MAINTAINERS | 2 ++
From: Elena Ufimtseva
Defines a PCI Device proxy object as a child of TYPE_PCI_DEVICE.
Signed-off-by: Elena Ufimtseva
Signed-off-by: Jagannathan Raman
Signed-off-by: John G Johnson
---
MAINTAINERS| 2 ++
hw/pci/Makefile.objs | 1 +
hw/pci/proxy.c | 80
From: Elena Ufimtseva
The entire array of the memory regions and file handlers.
Will be used in the next patch.
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
Reviewed-by: Stefan Hajnoczi
---
include/io/channel.h | 24
Initializes the message handler function in the remote process. It is
called whenever there's an event pending on QIOChannel that registers
this function.
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
---
MAINTAINERS | 1 +
hw/i386/
PCI host bridge is setup for the remote device process. It is
implemented using remote-pcihost object. It is an extension of the PCI
host bridge setup by QEMU.
Remote-pcihost configures a PCI bus which could be used by the remote
PCI device to latch on to.
Signed-off-by: Jagannathan Raman
Signed-
Allow RAM MemoryRegion to be created from an offset in a file, instead
of allocating at offset of 0 by default. This is needed to synchronize
RAM between QEMU & remote process.
Signed-off-by: Jagannathan Raman
Signed-off-by: John G Johnson
Signed-off-by: Elena Ufimtseva
Reviewed-by: Stefan Hajn
Add a configuration option to separate multi-process code
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
Signed-off-by: Elena Ufimtseva
Reviewed-by: Stefan Hajnoczi
---
configure | 11 +++
1 file changed, 11 insertions(+)
diff --git a/configure b/configure
index 2acc4
Hello
This is the v8 of the patchset. Thank you very much for the
detailed feedback for v7. We appreciate your time. We believe
we have address all the comments for v7 in the current series.
The broader items we have addressed in this series are as follows:
- Removed the main channel / control ch
On 31/07/20 14:51, Robert Foley wrote:
> This change removes the implied BQL from the cpu_handle_interrupt,
> and cpu_handle_exception paths. We can now select per-arch if
> the BQL is needed or not by using the bql_interrupt flag.
> By default, the core code holds the BQL.
> One benefit of this ch
On 31/07/20 19:53, John Snow wrote:
> You have misunderstood me.
>
> The critique I am relaying, but not raising, is that we already use a
> custom JSON parser in two or more places, and so replacing one instance
> of this with a new format actually complicates QEMU instead of
> simplifies it.
>
On 7/30/20 1:23 PM, Peter Maydell wrote:
> On Thu, 30 Jul 2020 at 21:06, Derrick McKee wrote:
>>
>> Hi Peter,
>>
>> I just got a SIGILL trying to execute a stg instruction with the QEMU
>> version later in this thread, but the same instruction works correctly on
>> the FVP. Are you sure that al
On 7/31/20 12:35 PM, Paolo Bonzini wrote:
On 31/07/20 17:26, John Snow wrote:
I saw the critique that we still use JSON-ish for the runtime QMP
protocol, and moving the QAPI IDL to a standard wouldn't remove all
instances of a custom format from our tree.
Sorry, but "still using JSON" is not a
On 31/07/20 19:20, Daniel P. Berrangé wrote:
> It also means QMP isn't easily extensible. eg if we used
> HTTP as our base, then we'd get remote TLS support for free from
> whatever library we used.
... and we would lose events, unless we do something with HTTP/2 and
streaming responses. We would
On Fri, Jul 31, 2020 at 08:51:26AM -0400, Robert Foley wrote:
> The new flag bql_interrupt, allows the CPUClass to
> determine if the BQL should be held during calls to
> cpu_exec_interrupt or do_interrupt.
>
> This is being added in preparation for changes in
> cpu_handle_interrupt, which will us
On 31/07/20 19:27, Daniel P. Berrangé wrote:
> You say "main feature", I say "biggest flaw" ;-P
>
> Doing checks on patches is the single worst thing about the way
> we do code style validation, at it means the bulk of committed code
> is never in compliance. The need to check patches is precisely
On 7/31/20 3:17 AM, Frank Chang wrote:
> On Fri, Jul 31, 2020 at 4:35 AM Richard Henderson
> I don't understand why there aren't more functions in this table. As far
> as I
> can see, the only NULLs should be at [*][0].
>
>
> As source EEW has to be 1/2, 1/4, 1/8 of SEW and the source
On Fri, Jul 31, 2020 at 07:16:54PM +0200, Paolo Bonzini wrote:
> >>> Another example would be adopting a standard code style and using a
> >>> tool like clang-format to enforce this for entire of existing code
> >>> base and future contributions and throwing away our checkpatch.pl
> >>> which near
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> +if (env->misa & RVV) {
> +/* TODO: support vlen other than 128, 256, 512 bits. */
> +const char *vector_xml_name = NULL;
> +switch (cpu->cfg.vlen) {
> +case 128:
> +vector_xml_name = "riscv-64bit-ve
On Fri, Jul 31, 2020 at 06:35:23PM +0200, Paolo Bonzini wrote:
> On 31/07/20 17:26, John Snow wrote:
> > I saw the critique that we still use JSON-ish for the runtime QMP
> > protocol, and moving the QAPI IDL to a standard wouldn't remove all
> > instances of a custom format from our tree.
>
> Sor
On 7/31/2020 11:52 AM, Daniel P. Berrangé wrote:
> On Fri, Jul 31, 2020 at 11:27:45AM -0400, Steven Sistare wrote:
>> On 7/31/2020 4:53 AM, Daniel P. Berrangé wrote:
>>> On Thu, Jul 30, 2020 at 02:48:44PM -0400, Steven Sistare wrote:
On 7/30/2020 12:52 PM, Daniel P. Berrangé wrote:
> On Th
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> +DEF_HELPER_5(vfncvt_rod_f_f_w_h, void, ptr, ptr, ptr, env, i32)
> +DEF_HELPER_5(vfncvt_rod_f_f_w_w, void, ptr, ptr, ptr, env, i32)
> +DEF_HELPER_5(vfncvt_rtz_xu_f_w_b, void, ptr, ptr, ptr, env, i32)
> +DEF_HELPER_5(vfncvt_rtz_xu_f_w_h, void, ptr,
On 31/07/20 19:05, Daniel P. Berrangé wrote:
> NB our files are not JSON documents, they are a concatenation of a list
> of JSON documents.
This is not something that editors generally have problems with.
> If you use javascript mode, then emacs will highlight all the javascript
> language keywo
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/helper.h | 6
> target/riscv/insn32.decode | 13 +---
> target/riscv/insn_trans/trans_rvv.inc.c | 43 +++--
> ta
On Fri, Jul 31, 2020 at 06:28:06PM +0200, Paolo Bonzini wrote:
> On 31/07/20 17:07, Daniel P. Berrangé wrote:
> > The QAPI JSON-but-not file format is a case where I think we should just
> > adopt a standard file format no matter what. A conversion will have some
> > short term work, but this is re
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/insn32.decode | 1 -
> target/riscv/insn_trans/trans_rvv.inc.c | 23 ---
> 2 files changed, 24 deletions(-)
Reviewed-by: Richard Henderson
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/helper.h | 6 --
> target/riscv/insn32.decode | 2 --
> target/riscv/insn_trans/trans_rvv.inc.c | 2 --
> target/riscv/vector_helper.c
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/helper.h | 22 ---
> target/riscv/insn32.decode | 7 -
> target/riscv/insn_trans/trans_rvv.inc.c | 9 --
> target/riscv/vector_helper.c
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> GEN_OPIVI_TRANS(vssrl_vi, IMM_ZX, vssrl_vx, opivx_check)
> -GEN_OPIVI_TRANS(vssra_vi, IMM_SX, vssra_vx, opivx_check)
> +GEN_OPIVI_TRANS(vssra_vi, IMM_ZX, vssra_vx, opivx_check)
>
I think both vssrl and vssra should use IMM_TRUNC_SEW.
r~
On 7/31/2020 5:06 AM, Daniel P. Berrangé wrote:
> On Thu, Jul 30, 2020 at 08:14:28AM -0700, Steve Sistare wrote:
>> From: Mark Kanda
>>
>> Iterate through the VNC displays and save/restore the socket fds.
>
> This patch doesn't appear to do anything around the client state, so I
> can't see how t
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> # Vector ordered and unordered reduction sum
> -vfredsum_vs -1 . . . 001 . 1010111 @r_vm
> +vfredsum_vs 01 . . . 001 . 1010111 @r_vm
> +vfredosum_vs11 . . . 001 . 1010111 @r_vm
"The vfr
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 31/07/20 17:26, John Snow wrote:
> > I saw the critique that we still use JSON-ish for the runtime QMP
> > protocol, and moving the QAPI IDL to a standard wouldn't remove all
> > instances of a custom format from our tree.
>
> Sorry, but "still usi
Am 31.07.2020 um 17:07 hat Daniel P. Berrangé geschrieben:
> On Fri, Jul 31, 2020 at 02:55:34PM +0200, Markus Armbruster wrote:
> > Daniel P. Berrangé writes:
>
> > >> Some of the criticism there doesn't matter for our use case.
> > >
> > > Yeah, what matters is whether it can do the job we nee
On 31/07/20 17:26, John Snow wrote:
> I saw the critique that we still use JSON-ish for the runtime QMP
> protocol, and moving the QAPI IDL to a standard wouldn't remove all
> instances of a custom format from our tree.
Sorry, but "still using JSON" is not a critique that makes any sense.
99% of
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> @@ -994,6 +994,12 @@ DEF_HELPER_5(vfcvt_f_xu_v_d, void, ptr, ptr, ptr, env,
> i32)
> DEF_HELPER_5(vfcvt_f_x_v_h, void, ptr, ptr, ptr, env, i32)
> DEF_HELPER_5(vfcvt_f_x_v_w, void, ptr, ptr, ptr, env, i32)
> DEF_HELPER_5(vfcvt_f_x_v_d, void, pt
On 31/07/20 17:07, Daniel P. Berrangé wrote:
> The QAPI JSON-but-not file format is a case where I think we should just
> adopt a standard file format no matter what. A conversion will have some
> short term work, but this is really simple data to deal with and the code
> involved is nicely self co
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/helper.h | 24 ++--
> target/riscv/insn32.decode | 12 +++---
> target/riscv/insn_trans/trans_rvv.inc.c | 12 +++---
> target/riscv/ve
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> +DEF_HELPER_6(vfslide1up_vf_h, void, ptr, ptr, i64, ptr, env, i32)
> +DEF_HELPER_6(vfslide1up_vf_w, void, ptr, ptr, i64, ptr, env, i32)
> +DEF_HELPER_6(vfslide1up_vf_d, void, ptr, ptr, i64, ptr, env, i32)
> +DEF_HELPER_6(vfslide1down_vf_h, void, p
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> -#define GEN_VEXT_VSLIDEDOWN_VX(NAME, ETYPE, H, CLEAR_FN) \
> +#define GEN_VEXT_VSLIDEDOWN_VX(NAME, ETYPE, H)\
> void HELPER(NAME)(void *vd, void *v0, target_ulong s1, void *vs2, \
>
On Fri, Jul 31, 2020 at 11:27:45AM -0400, Steven Sistare wrote:
> On 7/31/2020 4:53 AM, Daniel P. Berrangé wrote:
> > On Thu, Jul 30, 2020 at 02:48:44PM -0400, Steven Sistare wrote:
> >> On 7/30/2020 12:52 PM, Daniel P. Berrangé wrote:
> >>> On Thu, Jul 30, 2020 at 08:14:04AM -0700, Steve Sistare w
On Fri, Jul 31, 2020 at 11:26:28AM -0400, John Snow wrote:
> > The long answer is that as a general philosophy I'm in favour of agressively
> > eliminating anything that is custom to a project and isn't offering an
> > compelling benefit over a functionally equivalent, commonly used / standard
> >
Pincus, Josh writes:
> Hi,
>
>
>
> We were looking into a similar enhancement for the Virt I/O MMIO transport
> and came across this project.
>
> This enhancement would be perfect for us.
So there is certainly an interest in optimising MMIO based virtio and
the current read/ack cycle adds a
On 7/31/2020 4:53 AM, Daniel P. Berrangé wrote:
> On Thu, Jul 30, 2020 at 02:48:44PM -0400, Steven Sistare wrote:
>> On 7/30/2020 12:52 PM, Daniel P. Berrangé wrote:
>>> On Thu, Jul 30, 2020 at 08:14:04AM -0700, Steve Sistare wrote:
Improve and extend the qemu functions that save and restore V
On 7/31/20 11:07 AM, Daniel P. Berrangé wrote:
On Fri, Jul 31, 2020 at 02:55:34PM +0200, Markus Armbruster wrote:
Daniel P. Berrangé writes:
Some of the criticism there doesn't matter for our use case.
Yeah, what matters is whether it can do the job we need in a way that is
better than wha
On 7/31/2020 6:07 AM, Daniel P. Berrangé wrote:
> On Thu, Jul 30, 2020 at 02:11:19PM -0400, Steven Sistare wrote:
>> On 7/30/2020 12:20 PM, Eric Blake wrote:
>>> On 7/30/20 10:14 AM, Steve Sistare wrote:
Provide the -pause command-line parameter and the QEMU_PAUSE environment
variable to
On 7/22/20 2:16 AM, frank.ch...@sifive.com wrote:
> /* Vector Widening Integer Reduction Instructions */
> /* signed sum reduction into double-width accumulator */
> -GEN_VEXT_RED(vwredsum_vs_b, int16_t, int8_t, H2, H1, DO_ADD, clearh)
> -GEN_VEXT_RED(vwredsum_vs_h, int32_t, int16_t, H4, H2, DO_A
On Fri, Jul 31, 2020 at 02:55:34PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
> >> Some of the criticism there doesn't matter for our use case.
> >
> > Yeah, what matters is whether it can do the job we need in a way that is
> > better than what we have today, and whether there
On Sat, 11 Jul 2020 at 11:10, Andrew Jones wrote:
> We add the kvm-steal-time CPU property and implement it for machvirt.
> A tiny bit of refactoring was also done to allow pmu and pvtime to
> use the same vcpu device helper functions.
>
> Signed-off-by: Andrew Jones
Hi; I'm forwarding a couple
qemu (1:5.0-5ubuntu3) groovy; urgency=medium
has the merge with this fix:
- linux-user-add-netlink-RTM_SETLINK-command.patch (Closes: #964289)
** Changed in: qemu (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml,
On Fri, Jul 31, 2020 at 10:39:37AM +0200, Roman Mohr wrote:
> On Fri, Jul 31, 2020 at 10:26 AM Stefan Hajnoczi
> wrote:
>
> > On Thu, Jul 30, 2020 at 06:21:34PM -0400, Daniel Walsh wrote:
> > > On 7/29/20 10:40, Stefan Hajnoczi wrote:
> > > > On Wed, Jul 29, 2020 at 09:59:01AM +0200, Roman Mohr w
On Fri, Jul 31, 2020 at 08:46:40AM -0500, Eric Blake wrote:
> On 7/31/20 2:44 AM, Markus Armbruster wrote:
>
> > > > Thread_id should be optional and thus not filled in if we
> > > > can't provide a sensible value. Unfortunately we made it
> > > > mandatory in QMP.
> > >
> > > Normally, convertin
On 7/31/20 2:44 AM, Markus Armbruster wrote:
Thread_id should be optional and thus not filled in if we
can't provide a sensible value. Unfortunately we made it
mandatory in QMP.
Normally, converting a mandatory output value to optional is a
back-compatibility risk (we could break apps that dep
On Fri, 31 Jul 2020 10:37:34 +0100
Daniel P. Berrangé wrote:
> On Fri, Jul 31, 2020 at 11:27:04AM +0200, Lukas Straub wrote:
> > yank_register_instance (called when creating the new chardev object)
> > aborts if the instance already exists. So check for duplicate id before
> > creating the new ch
Daniel P. Berrangé writes:
> On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé writes:
>>
>> > modify them so that we can load the
>> > files straight into the python intepretor as code, and not parse
>> > them as data. I fe
The new flag bql_interrupt, allows the CPUClass to
determine if the BQL should be held during calls to
cpu_exec_interrupt or do_interrupt.
This is being added in preparation for changes in
cpu_handle_interrupt, which will use this flag.
Signed-off-by: Robert Foley
---
hw/core/cpu.c | 1
This change removes the implied BQL from the cpu_handle_interrupt,
and cpu_handle_exception paths. We can now select per-arch if
the BQL is needed or not by using the bql_interrupt flag.
By default, the core code holds the BQL.
One benefit of this change is that it leaves it up to the arch
to make
The purpose of this change is to set the groundwork
so that an arch could move towards removing
the BQL from the cpu_handle_interrupt/exception paths.
The BQL is a bottlneck in scaling to more cores.
And this cpu_handle_interrupt/exception path is one of
the key BQL users as measured by the QEMU s
Am 31.07.2020 um 11:01 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 30.07.2020 um 17:11 hat Eric Blake geschrieben:
> >> > JSON is a exceptionally poor choice for a DSL, or even a configuration
> >> > language.
> >> >
> >> > Correcting our mistake involves a flag day and a re
On 7/31/20 12:09 AM, Paolo Bonzini wrote:
> On 30/07/20 18:33, Claudio Fontana wrote:
>> One problem I noticed is that qemu_clock_get_ns is util/qemu-timer.c,
>> which is tools _and_ softmmu, while I tried to extract the
>> softmmu-only timer code in softmmu/cpu-timers.c,
>
> Not all of it, only t
> -Original Message-
> From: Lukas Straub
> Sent: Friday, July 31, 2020 1:06 PM
> To: qemu-devel
> Cc: Peter Maydell ; Jason Wang
> ; Zhang, Chen
> Subject: [PATCH] colo-compare: Remove superfluous NULL-pointer checks
> for s->iothread
>
> s->iothread is checked for NULL on object cr
On 7/31/20 1:25 PM, Stefan Hajnoczi wrote:
> On Fri, Jul 10, 2020 at 08:27:09PM +0300, Denis V. Lunev wrote:
>> There are severe delays with IO requests processing if QEMU is running in
>> virtual machine or over software defined storage. Such delays potentially
>> results in unpredictable guest be
m/cohuck/qemu tags/s390x-20200731
>
> for you to fetch changes up to 148d25e0f6ad1dc3bd6aace092d65262d4217ec6:
>
> s390x/s390-virtio-ccw: fix off-by-one in loadparm getter (2020-07-30
> 16:53:34 +0200)
>
> --
On Fri, Jul 10, 2020 at 08:27:09PM +0300, Denis V. Lunev wrote:
> There are severe delays with IO requests processing if QEMU is running in
> virtual machine or over software defined storage. Such delays potentially
> results in unpredictable guest behavior. For example, guests over IDE or
> SATA d
Lukas Straub 于2020年7月31日周五 下午1:09写道：
>
> s->iothread is checked for NULL on object creation in colo_compare_complete,
> so it's guaranteed not to be NULL.
> This resolves a false alert from Coverity (CID 1429969).
>
> Signed-off-by: Lukas Straub
Reviewed-by: Li Qiang
> ---
> net/colo-compare.
On Wed, Jul 29, 2020 at 02:06:43PM +0300, Denis V. Lunev wrote:
> On 7/29/20 1:30 PM, Stefan Hajnoczi wrote:
> > On Fri, Jul 10, 2020 at 08:27:11PM +0300, Denis V. Lunev wrote:
> >> @@ -3740,6 +3741,10 @@ QemuOptsList qemu_common_drive_opts = {
> >> .type = QEMU_OPT_BOOL,
> >>
1 - 100 of 146 matches
Mail list logo
