On 12/11/19 7:59 PM, Alex Bennée wrote:
>
> Damien Hedde writes:
>
>> Since we can now send packets of arbitrary length:
>> simplify gdb_monitor_write() and send the whole payload
>> in one packet.
>
> Do we know gdb won't barf on us. Does the negotiated max packet size
> only apply to data
There's a couple of places left in the qcow2 code that still do the
calculation manually, so let's replace them.
Signed-off-by: Alberto Garcia
---
block/qcow2.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 7c18721741..3866b47946
On Thu, Dec 12, 2019 at 5:22 AM Richard Henderson
wrote:
>
> Reduce the amount of preprocessor obfuscation by expanding
> the text of each of the functions generated. The result is
> only slightly smaller than the original.
>
I am not sure what you meant by "The result is only slightly smaller
Le 12/12/2019 à 05:00, Richard Henderson a écrit :
> The generated *_user functions are unused. The *_kernel functions
> have a couple of users in op_helper.c; use *_mmuidx_ra instead,
> with MMU_KERNEL_IDX.
>
> Cc: Laurent Vivier
> Signed-off-by: Richard Henderson
> ---
> target/m68k/cpu.h
Hi,
> > First the addressing is non-trivial, especially with the "transport
> > specific device address" in the tuple.
>
> There is complexity here, but I think it would also be present in the
> buffer sharing device case. With a buffer sharing device, the same
> identifying information would
On 12/11/19 7:58 PM, Philippe Mathieu-Daudé wrote:
> On 12/11/19 5:05 PM, Damien Hedde wrote:
>> Since we can now send packets of arbitrary length:
>> simplify gdb_monitor_write() and send the whole payload
>> in one packet.
>
> While we can send arbitrary length on the wire, we advertise
>
On Thu, Dec 12, 2019 at 5:07 AM Richard Henderson
wrote:
>
> There are no uses of the *_cmmu names other than the bare wrapping
> within the *_code inlines. Therefore rename the functions so we
> can drop the inlines.
>
> Use abi_ptr instead of target_ulong in preparation for user-only;
> the
On Thu, Dec 12, 2019 at 5:21 AM Richard Henderson
wrote:
>
> The separate suffixed functions were used to construct
> some do_##insn function switched on mmu_idx. The interface
> is exactly identical to the *_mmuidx_ra functions. Replace
> them directly and remove the constructions.
>
> Cc:
On Tue, Dec 10, 2019 at 8:18 AM Michael Rolnik wrote:
>
> You are right. See at the bottom of the file. There is a comment about it
>
Sorry, what file?
I also see that you disassemble instructions regardless of what AVR
CPU the current executable is built for, don't you? OK, not a very big
On Thu, Dec 12, 2019 at 08:34:57AM +0100, Cédric Le Goater wrote:
> Hello Bharata,
>
>
> On 12/12/2019 06:50, Bharata B Rao wrote:
> > A pseries guest can be run as a secure guest on Ultravisor-enabled
> > POWER platforms. When such a secure guest is reset, we need to
> > release/reset a few
Le 12/12/2019 à 05:00, Richard Henderson a écrit :
> The generated *_user functions are unused. The *_kernel functions
> have a couple of users in op_helper.c; use *_mmuidx_ra instead,
> with MMU_KERNEL_IDX.
>
> Cc: Laurent Vivier
> Signed-off-by: Richard Henderson
> ---
> target/m68k/cpu.h
On 12/11/2019 01:35 PM, Igor Mammedov wrote:
On Wed, 11 Dec 2019 09:44:11 +0530
Shivaprasad G Bhat wrote:
On 12/06/2019 07:22 AM, David Gibson wrote:
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
Fix a small memory leak in the Bochs display driver.
Each frame would leak about 304 bytes.
v2: Add missing signed-off-by line.
v3: Add reviewed-by and fixes lines.
Cameron Esfahani (1):
display/bochs-display: fix memory leak
hw/display/bochs-display.c | 2 ++
1 file changed, 2
Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame.
Fixes: 33ebad54056
Signed-off-by: Cameron Esfahani
Reviewed-by: Philippe Mathieu-Daudé
---
hw/display/bochs-display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/display/bochs-display.c
Richard Henderson writes:
> On 12/11/19 9:05 AM, Alex Bennée wrote:
>> +static struct TypeSize vec_lanes[] = {
>
> const.
>
>> +case 51:
>> +return gdb_get_reg64(buf, (cpu->env.vfp.zcr_el[1] & 0xf) + 1);
>
> You need to use sve_zcr_len_for_el to get the effective vq.
> Also, I
On 11/12/19 14:32, Greg Kurz wrote:
> QOM interfaces allow a limited form of multiple inheritance, at the
> condition of being stateless. That is, they cannot be instantiated
> and a pointer to an interface shouldn't be dereferenceable in any way.
> This is achieved by making the QOM instance type
On 12/12/19 05:00, Richard Henderson wrote:
> The functions generated by these macros are unused.
>
> Cc: Paolo Bonzini
> Cc: Eduardo Habkost
> Signed-off-by: Richard Henderson
> ---
> target/i386/cpu.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/target/i386/cpu.h
401 - 417 of 417 matches
Mail list logo
