On 07/10/2012 02:52 PM, Anthony Liguori wrote: > On 07/10/2012 12:57 AM, Hannes Reinecke wrote: >> 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. > > But it's not stable across migration. That's the problem. > >> The whole thing is informational anyway, and can only be seen when >> using the (proprietary) MegaCLI userspace command. > > Nonetheless, it's still guest visible. >
Okay, I see your point. I'll be reworking things to not use the pointer here. >>> 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. > > You could used a hashed uuid. > Right. Will see how that'll work out. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +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)