From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH 11/13] libxl: set nic type to VIF by default
Date: Mon, 11 Jun 2012 15:05:04 +0100
Message-ID: <4FD5FB10.2090406@citrix.com>
References: <1337184716-49276-1-git-send-email-roger.pau@citrix.com>
	<1337184716-49276-12-git-send-email-roger.pau@citrix.com>
	<20406.31676.266501.253510@mariner.uk.xensource.com>
	<4FBA6D52.9050809@citrix.com>
	<20420.57290.841831.831419@mariner.uk.xensource.com>
	<1338302817.14158.120.camel@zakaz.uk.xensource.com>
	<4FC60CA8.4090404@citrix.com>
	<20432.47897.707481.695066@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20432.47897.707481.695066@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF by default"):
>> If this is right, I have to change my hotplug patches, but this will be
>> a mess, because I have no way to tell if a domain is PV or HVM when
>> plugging in the devices, so if VIF is passed for both PV or PV+TAP I
>> will have no way of knowing that.
>
> Hmmm.
>
>> Should we create three different nic types? VIF (PV), IOEMU (TAP),
>> HYBRID (PV+TAP)?
>
> I think this might be better.  Or alternatively, always provide PV,
> and have a flag which says `do provide ioemu'.

This looks reasonable given the current types of nic interfaces.

>
> I think it's very confusing if setting the `type' to `ioemu' rather
> than `pv' means `do provide pv but provide ioemu as well'.
>
> Another way of looking at it is: if we wanted to provide some other
> interfaces (besides Xen PV and emulated PCI) in the future, would it
> be an alternative to PV or to PCI or something additional ?

I have no idea, could someone shed some light on this?