linux-kernel - Re: [RFC PATCH] nForce4 ADMA with NCQ: It's aliiiive..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <452F053B.2000906@shaw.ca>
Date:	Thu, 12 Oct 2006 21:17:15 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Allen Martin <AMartin@...dia.com>, Jeff Garzik <jeff@...zik.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, prakash@...noor.de
Subject: Re: [RFC PATCH] nForce4 ADMA with NCQ: It's aliiiive..

Jens Axboe wrote:
> On Tue, Oct 10 2006, Robert Hancock wrote:
>> Allen Martin wrote:
>>>> But I really don't think that is necessary.  I will take a 
>>>> look at docs and see how things match up, when I am much more 
>>>> awake.  Most likely you need to be using another set of 
>>>> registers, and be all MMIO, all the time.
>>> You shouldn't be touching BM registers when ADMA is enabled, it can
>>> cause bad things to happen.
>>>
>>> You should be using BM registers when doing ATAPI protocol though, as it
>>> doesn't work through ADMA.  So I wouldn't say you should be using MMIO
>>> all the time.
>>>
>>> -Allen
>> OK, I've updated the code to take this into account, an updated patch is 
>> attached. However, this does raise an issue. If we have to fall back to 
>> legacy mode to do ATAPI DMA, this means that we can't do 64-bit DMA for 
>> such transfers. Since by the time the driver gets a request the SGs have 
>> already been created based on the set DMA mask, the only way I can see 
>> to handle this is to either allow ATAPI DMA or 64-bit DMA, not both. 
>> I've chosen to default to 64-bit DMA in this version, but there is a 
>> module parameter which allows overriding this if you care more about 
>> using ATAPI devices than efficiency with over 4GB of RAM. I'm open to 
>> suggestions on a better way to handle this..
> 
> Should be easily fixable - in general, set 64-bit dma mask. Then when
> you detect an atapi device, lower the dma mask settings to 32-bit dma
> for that device only. So the pci device in question gets a full 64-bit
> dma mask, the attached scsi devices can have lower masks if necessary.
> I'd suggest doing this off slave config.
> 

I think that should be feasible.. However, one problem is that 
slave_config only has access to the struct scsi_device and the 
ata_scsi_find_dev function to turn that into a struct ata_device isn't 
exported, which it would need to be in order to do anything useful 
inside the driver for slave_config. We could export it, or I suppose the 
other place we could do this handling would be postreset, as at that 
point we should know what kind of device is attached.. any comments?

Also, how is the driver supposed to be setting the DMA mask for the SCSI 
device? I suppose blk_queue_bounce_limit would work, but it seems a bit 
odd to use block layer calls at the libata driver level.

I also noticed that I'm still using the default 64KB libata dma_boundary 
value, this should be 4GB for ADMA mode (but fixed up back to the 
default if an ATAPI device is connected, same as with the DMA mask).

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/