[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.