[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/14] SCSI updates for 2012-07-02

From: Hannes Reinecke
Subject: Re: [Qemu-devel] [PULL 00/14] SCSI updates for 2012-07-02
Date: Tue, 10 Jul 2012 07:57:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0

On 07/10/2012 01:19 AM, Anthony Liguori wrote:
> On 07/09/2012 06:09 PM, Alexander Graf wrote:
>> On 09.07.2012, at 18:48, Anthony Liguori wrote:
>>> On 07/02/2012 04:41 AM, Paolo Bonzini wrote:
>>>> Anthony,
>>>> The following changes since commit
>>>> 71ea2e016131a9fcde6f1ffd3e0e34a64c21f593:
>>>>    bsd-user: fix build (2012-06-28 20:28:36 +0000)
>>> Pulled.  Thanks.
>> Megasas? :)
> So this code is really broken:
>     info.host.type = MFI_INFO_HOST_PCIX;
>     info.device.type = MFI_INFO_DEV_SAS3G;
>     info.device.port_count = 2;
>     info.device.port_addr[0] =
> cpu_to_le64(megasas_gen_sas_addr((uint64_t)s));
> This will make migration impossible not to mention the fact that
> casting a pointer to a uint64_t is really broken.
Hey, this is _NOT_ an address. It's a simple way of generating a
system-wide unique SAS address.

The whole thing is informational anyway, and can only be seen when
using the (proprietary) MegaCLI userspace command.

> This code needs to be refactored to not do this.  It's quite
> pervasive though (there's a half a dozen instances like this).

Okay, so here's the challenge: We need to generate a system-wide
unique SAS address, one per SCSI device and one per megasas instance.
A simple counter won't work, as we might have several qemu instances
running. Which would result in all of them having the same SAS
address for the host.

> I'm going to disable the build by default.  I don't want to see a
> rash fix like (uint64_t)(intptr_t).  This needs to be fixed by not
> making the pointer address guest visible.  It can then be
> re-enabled.  Should be easy enough to update your .mak config if you
> want to test between now and then.
As said, it's _not_ an address. The address it just use to seed the
SAS address.

But as you object, I see to use something else for seeding the SAS


Dr. Hannes Reinecke                   zSeries & Storage
address@hidden                        +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]