From owner-freebsd-virtualization@FreeBSD.ORG Tue Jun 4 16:23:25 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 938804BD for ; Tue, 4 Jun 2013 16:23:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 260E01C70 for ; Tue, 4 Jun 2013 16:23:24 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jf17so288823bkc.7 for ; Tue, 04 Jun 2013 09:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=i7wUhgYCQpqMHmsNnJaK7eLZnnsbFaqplQe2ZN49+LY=; b=f4MbNsDglKyM+Vgn4J6N9sCefuN1K9sBs/V3KmOwSft68CYV1Suqtu80zcyrHZpfpa /uSlW9MgffCoFZ2gau0S6CwLnz9Zt2RYRWpdcSJWbt9bEqDMketVTKKtbkaKHxcZjVsD ktSGODk9g4eec3nPc7id56C62RgtXA9hBis2u/egFCyaJms/DOu95zPKgP4NwcyrnCPX fOLJNY3bo542l7w0U+xNpZDopPmmNRpuMnuWgAJJxpMNgISF7AfRUmgsqtt17BGwrCaJ JGeHBcMH6dB5G+AUgr0vvfpXp+PD2srmkEavHXdafEv62ZK8YkpjI4jfOA2W7IWv6ytY 2aFA== X-Received: by 10.204.187.9 with SMTP id cu9mr8446831bkb.104.1370363004198; Tue, 04 Jun 2013 09:23:24 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id iy11sm23591341bkb.11.2013.06.04.09.23.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 09:23:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <51AE1478.2000409@FreeBSD.org> Date: Tue, 04 Jun 2013 19:23:20 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Larry Melia Subject: Re: more granular detection and control to disable/enable PCI-ATA devices References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Abhishek Gupta \(LIS\)" , KY Srinivasan , freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:23:25 -0000 Hi. On 04.06.2013 18:30, Larry Melia wrote: > With you suggestions, I finally was able to get the override driver > working-see > https://github.com/FreeBSDonHyper-V/freebsd-snapshot/blob/hyperv-dev-ata-override/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c. > While it operates wonderfully, allowing our "enlightened" driver to > improve performance, some versions of Hyper-V still use the native > CD-ROM driver, because there is no "enlightened" support for it in the > hypervisor. From my limited knowledge of the ATA drivers, it seems > likely that the PCI-ATA driver be attached when a CD-ROM is detected, > but lower-level drivers disabled (during a probe) when a hard drive is > detected. On Hyper-V, therefore, a user would be able to configure a > PCI/IDE virtual controller with two devices, the first device a hard > disk and the second one a CD-ROM. The CD-ROM would operate via the > native driver, whereas the hard disk would use the "enlightened" driver > (to improve performance). Is there an easy way to add more granular > detection, disabling the native ATA driver(s) selectively for hard > drives, while allowing CD-ROM devices to be natively attached? Any > suggestions would be very much appreciated. Unfortunately, CAM subsystem used for both ATA and SCSI stacks in FreeBSD 9.x and above is mostly unaware of "NewBus" infrastructure used for driver probe and attachment. That is why you can't replace driver for a single disk in the same way as you replaced driver for the whole controller. The highest level present in "NewBus" is ATA channel. So if disk and CD-ROM are always live on different channels, you can create dummy driver not for the whole controller (atapciX), but for single hardcoded ATA channel (ataX). Another possible way is to make controller driver not dummy, making it mostly duplicating default one, but filtering out unwanted devices. That may look like overkill, but it is not necessary so, because ATA stack is quite modularized, and you probably don't need to implement all ATA functionality such as mode setting, etc. Only thing that should be different in your driver is a reset method -- never reporting ATA disks to upper layers, only ATAPI devices. You may find number of drivers for example in sys/dev/ata/chipsets. The later way is definitely more complicated then just a few lines hack blocking CAM ada driver (ATA disk driver), but it still can be made modular and non-invasive. -- Alexander Motin