[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120419074018.GA3342@shadowen.org>
Date: Thu, 19 Apr 2012 08:40:18 +0100
From: Andy Whitcroft <apw@...onical.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: KY Srinivasan <kys@...rosoft.com>, Jeff Garzik <jgarzik@...ox.com>,
"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mike Sterling <mike.sterling@...rosoft.com>
Subject: Re: [PATCH 0/2] Hyper-V disk support V3
On Wed, Apr 18, 2012 at 09:12:35PM +0100, Alan Cox wrote:
> > The notion of "pass through" in Hyper-V is a little different. IDE devices can be configured
> > under either one of the supported controllers and these devices can either be virtual disks
> > (VHDs) or physical disks. In either case these will be presented to the guest as IDE devices.
>
> So what ensures that by skipping it at the ATA device level we will
> always find it as a VHD ?
My understanding of things is that the if you have disks assigned to the
guest that they will always appear both on the virtualised SATA contoller
and on the paravirtualised driver channel. So that assuming a valid
configuration in which both drivers initialise they will be picked up by
one or the other.
KY for clarity are we saying the only way a disk can appear in the guest
is either on the emulated controller or paravirtualised, we will never
expose real devices into the guest.
Reading my own statement that ought to imply we really should only default
preferring paravirtualised to 'on' when the hyperv paravirtualised drivers
is enabled too; easy enough to do. Howeever in a perfect world the
override would also have the inverse effect even if the paravirtualised
driver initialises first; not so easy but I assume we with some fiddling
we could make both drivers handle the same parameter.
/me considers this further.
-apw
--
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/
Powered by blists - more mailing lists