> On 03/28/2018 12:20 PM, Peter Xu wrote:
>> On Wed, Mar 28, 2018 at 12:08:19PM +0800, jiang.bi...@zte.com.cn wrote:
On Tue, Mar 27, 2018 at 10:35:29PM +0800, Xiao Guangrong wrote:
>>> No, we can't make the assumption that "error _must_ be caused by page
>>> update".
>>>
>
> On Tue, Mar 27, 2018 at 10:35:29PM +0800, Xiao Guangrong wrote:
>
>> > > No, we can't make the assumption that "error _must_ be caused by page
>> > > update".
>> > > No document/ABI about compress/decompress promised it. :)
>
> Indeed, I found no good documents about below errors that jiang.b
> On 03/27/2018 07:17 PM, Peter Xu wrote:
>> On Tue, Mar 27, 2018 at 03:42:32AM +0800, Xiao Guangrong wrote:
>>
>> [...]
>>
It'll be understandable to me if the problem is that the compress()
API does not allow the input buffer to be changed during the whole
period of the call. If
Hi, guangrong
> @@ -1051,11 +1052,13 @@ static int do_compress_ram_page(QEMUFile *f, z_stream
> *stream, RAMBlock *block,
> {
> RAMState *rs = ram_state;
> int bytes_sent, blen;
> -uint8_t *p = block->host + (offset & TARGET_PAGE_MASK);
> +uint8_t buf[TARGET_PAGE_SIZE], *p;
> +p = blo
>>> +err = deflate(stream, Z_FINISH);
>>> +if (err != Z_STREAM_END) {
>>> +return -1;
>>> +}
>>> +
>>> +return stream->next_out - dest;
>>> +}
>>> +
>>>
>>> @@ -683,8 +707,10 @@ ssize_t qemu_put_compression_data(QEMUFile *f, const
>>> uint8_t *p, size_t size,
>>> return -1;
Hi, guangrong
>
> +/* return the size after compression, or negative value on error */
> +static int qemu_compress_data(z_stream *stream, uint8_t *dest, size_t
> dest_len,
> + const uint8_t *source, size_t source_len)
> +{
> +int err;
> +
> +err = deflateReset
> On 11/02/2017 12:23 PM, jiang.bi...@zte.com.cn wrote:
> > No, :) Just found some of these functions are inline and others are not
> > when reading
> > the code, the style looks inconsistent.
> >
> My preference would be to remove them all.
Should I commit another patch to do that? :)
> > Besid
> On 11/02/2017 11:26 AM, Jiang Biao wrote:> > Make some functions inline.
>
> Why?
>
> Do you have evidence that the compiler isn't making reasonable default choices
> with respect to inlining?
No, :) Just found some of these functions are inline and others are not when
reading
the code, the s
> On 11 October 2017 at 05:33, Jiang Biao wrote:
>
> I'd rather not drop this to a warning for the sake of a single
> use case that's already in the tree (and which if you really
> cared about you could work around by putting the link_error()
> declaration in a header file I suppose, though I wou
> On 10 October 2017 at 08:54, Jiang Biao wrote:
> > When adding a function declaration in a .c file without extern
> >keywork decoration, checkpatch.pl will report *externs should be
> > avoided in .c files* false error. This patch fixes the bug.
>
> I don't think this is a bug. "extern int fo
> For this specific case, the primary problem will be the implicit memory
> barriers that the i386 guest requires, but that the mips64 host does not
> provide.
>
> For tcg/mips/, TCG_TARGET_DEFAULT_MO should be 0, because the mips
> architecture
> does not have any implicit memory ordering. A
> On 07/18/2017 02:22 PM, jiang.bi...@zte.com.cn wrote:
> > Seeing your work on multiple TCG, it seems that it has some kind of
> > connection
> > with the MTTCG feature,
> >
> > but I do not figure out how they are connected in detail.
> >
> > Could you pls help to confirm the following qu
Hi,
Seeing your work on multiple TCG, it seems that it has some kind of connection
with the MTTCG feature,
but I do not figure out how they are connected in detail.
Could you pls help to confirm the following questions:
what is the relationship between your patches and the MTTCG feature menti
> On 07/09/2017 11:12 PM, Jiang Biao wrote:
> > Reserve a register for the guest_base using ppc code for reference.
> > By doing so, we do not have to recompute it for every memory load.
> >
> > Signed-off-by: Jiang Biao
> > Signed-off-by: Richard Henderson
> > ---
> > tcg/mips/tcg-target.inc.c
> > this section of code is to extend the addr_regl to 64bit, and use *base* as
> > temp
> > intermedia. The real intention could be to extend addr_regl into base, and
> > then
> > move base back to addr_regl for later use, but it wrongly assigning base to
> > addr_regl directly, which will
> On 07/09/2017 04:04 PM, jiang.bi...@zte.com.cn wrote:
> > >> if (TCG_TARGET_REG_BITS > TARGET_LONG_BITS) {
> > >> tcg_out_ext32u(s, base, addr_regl)
> > >> -addr_regl = base
> > >> +tcg_out_mov(s, TCG_TYPE_PTR, addr_regl, base)
> > >> }
> > >> if
>> if (TCG_TARGET_REG_BITS > TARGET_LONG_BITS) {
>> tcg_out_ext32u(s, base, addr_regl)
>> -addr_regl = base
>> +tcg_out_mov(s, TCG_TYPE_PTR, addr_regl, base)
>> }
>> if (guest_base == 0 && data_regl != addr_regl) {
>> base = addr_regl
>
> Th
>
> This is wrong, because you're not allowed to modify the input operands.
>
> Try this, just a few lines lower in the function:
>
> -tcg_out_movi(s, TCG_TYPE_PTR, base, guest_base)
> -tcg_out_opc_reg(s, ALIAS_PADD, base, base, addr_regl)
> +tcg_out_movi(s, TCG_TYPE_PT
18 matches
Mail list logo
