linux-kernel - Re: [PATCH 1/3] block: add queue flag for paravirt frontend drivers

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: <4910D97E.2030203@goop.org>
Date:	Tue, 04 Nov 2008 15:23:42 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, rusty@...tcorp.com.au,
	linux-kernel@...r.kernel.org, jeremy@...source.com
Subject: Re: [PATCH 1/3] block: add queue flag for paravirt frontend drivers

Jens Axboe wrote:
> On Mon, Oct 27 2008, Fernando Luis Vázquez Cao wrote:
>   
>> As is the case with SSD devices, we do not want to idle in AS/CFQ when
>> the block device is a paravirt front-end driver. This patch adds a flag
>> (QUEUE_FLAG_VIRT) which should be used by front-end drivers such as
>> virtio_blk and xen-blkfront to indicate a paravirtualized device.
>>     
>
> All three patches look fine, although we could just reuse
> QUEUE_FLAG_NONROT directly. But I agree it makes sense to make the
> distinction, so I've just applied 1-3.
>   

I guess in theory you could imagine that the virtual device is mapped 
directly onto a physical device, and the host OS does no scheduling, in 
which case it would be appropriate for the guest do the work.  But I 
think otherwise this makes sense.

    J
--
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/