All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Slutz <Don@CloudSwitch.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] hw: Add support for new LSI Logic devices.
Date: Sat, 29 Sep 2012 10:35:02 -0400	[thread overview]
Message-ID: <50670716.8050604@CloudSwitch.com> (raw)
In-Reply-To: <87ligdbpzr.fsf@codemonkey.ws>

On 09/13/12 16:57, Anthony Liguori wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
>> On Tue, Sep 11, 2012 at 01:00:13PM -0400, Don Slutz wrote:
>>> +            if (next_chain_offset) {
>>> +                MptSGEntryChain sgec;
>>> +                cpu_physical_memory_read(seg_start_pa + next_chain_offset,
>>> +                        &sgec, sizeof(MptSGEntryChain));
>>> +                assert(sgec.u2ElementType == MPTSGENTRYTYPE_CHAIN);
>>> +                next_sge_pa = sgec.u32SegmentAddressLow;
>>> +                if (sgec.f64BitAddress) {
>>> +                    next_sge_pa |=
>>> +                        ((uint64_t)sgec.u32SegmentAddressHigh) << 32;
>>> +                }
>>> +                seg_start_pa = next_sge_pa;
>>> +                next_chain_offset = sgec.u8NextChainOffset * sizeof(uint32_t);
>> BTW all this logic seems wrong on big endian.
>> Maybe we don't care short term but we do long term.
> I think we care short term.  It's easy enough to copy and past but i'm
> not inclined to believe this will be maintained longer term if someone
> makes the investment to de-uglify things.
How important is the big endian support?

lsi53c895a.c says:

/* ??? Need to check if the {read,write}[wl] routines work properly on
    big-endian targets.  */

I could do the same, I.E. code it up and submit it un-tested on big 
endian soon.  Or since I currently do not have access to any real big 
endian hardware;  do all testing on QEMU on QEMU.

> I can tolerate a lot, but I'm not going to pull something with variable
> names of 'u8NextChainOffset' :-)  Changing this in tree is just
> unnecessary churn.

I have re-worked the variable names.  For example:

             if (next_chain_offset) {
                 MptSGEntryChain sgec;
                 cpu_physical_memory_read(seg_start_pa + next_chain_offset,
                                          &sgec, sizeof(MptSGEntryChain));
                 assert(sgec.element_type == MPTSGENTRYTYPE_CHAIN);
                 next_sge_pa = sgec.segment_address_low;
                 if (sgec.bit_address) {
                     next_sge_pa |=
                         ((uint64_t)sgec.segment_address_high) << 32;
                 }
                 seg_start_pa = next_sge_pa;
                 next_chain_offset = sgec.next_chain_offset * 
sizeof(uint32_t);

Does this look better?

> Regards,
>
> Anthony Liguori
>
>> I think you need to fix it up using le_to_cpu or something.
>> And in particular this likely means bitfields can not be used cleanly,
>> so you will not be able to resync lsilogic.h from virtualbox.
>> The implication I guess is that we should just fix up the style
>> to match qemu.
>>
>> -- 
>> MST
   -Don Slutz

  reply	other threads:[~2012-09-29 14:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 17:00 [Qemu-devel] [PATCH] hw: Add support for new LSI Logic devices Don Slutz
2012-09-11 23:50 ` Michael S. Tsirkin
2012-09-12  6:01   ` Paolo Bonzini
2012-09-12 12:36   ` Kevin Wolf
2012-09-12 13:58     ` Anthony Liguori
2012-09-13  6:24       ` Paolo Bonzini
2012-09-13 13:14         ` Anthony Liguori
2012-10-04 13:45         ` Hannes Reinecke
2012-09-13 12:43       ` Don Slutz
2012-09-12  6:58 ` Gerhard Wiesinger
2012-09-13 17:10   ` Don Slutz
2012-09-12 15:38 ` Avi Kivity
2012-09-13 12:46   ` Don Slutz
2012-09-13 13:54 ` Michael S. Tsirkin
2012-09-13 20:57   ` Anthony Liguori
2012-09-29 14:35     ` Don Slutz [this message]
2012-10-01 14:25       ` Paolo Bonzini
2012-11-08 19:03 ` Gerhard Wiesinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50670716.8050604@CloudSwitch.com \
    --to=don@cloudswitch.com \
    --cc=anthony@codemonkey.ws \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.