Re: [Xen-devel] [PATCH v4] add support for libvirt-like channels

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-07-28 at 15:22 +0100, David Vrabel wrote:
> On 22/07/14 16:05, David Scott wrote:
> > 
> > Note: I've seen a problem with some Linux console frontends which attempt
> > to overwrite the read-only key 'type' (= xenconsoled|ioemu) in the frontend
> > directory. [ this key is already present, it's not added by these patches ]
> > Since 'type' refers to the toolstack's choice of implementation service
> > (which is none of the guest's business) I think the read/only permissions
> > are right. The location of the key is not ideal (it should be in the
> > backend directory IMHO) but this is the case with several other keys located
> > in the frontend such as 'limit' and 'tty'.

I think this probably arose because the first PV console is not (or at
least historically wasn't) a normal front/back pair so I think it may
only have had a f.e. directory. It's likely that this then carried over
into the support for multiple console channels which do follow the
front/back model.

>  I think this is a Linux frontend
> > bug which should be fixed there.

Yeah, irrespective of the above it was never right for the frontend to
try and write this node AFAICT.

>  These patches work with Mirage VMs and
> > with Linux if I workaround the permissions by giving the guest read/write
> > to the 'type' key. 
> 
> Which Linux frontends?

Did this get answered/sorted (if so then I'm afraid I've lost that
subthread).

Any idea why this only happens with these patches, since as you say the
node is already there?

Does this affect the primary console device or only secondary ones? Or
perhaps only secondary ones created using this channels infrastructure? 

I'm trying to get a feel for how worried I should be about the potential
for regressing existing guests with this change.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel