qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] s390x/css: generate channel path initialize


From: Dong Jia Shi
Subject: Re: [Qemu-devel] [PATCH 3/3] s390x/css: generate channel path initialized CRW for channel path hotplug
Date: Tue, 1 Aug 2017 09:23:04 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

* Cornelia Huck <address@hidden> [2017-07-31 10:41:47 +0200]:

> On Mon, 31 Jul 2017 09:46:17 +0800
> Dong Jia Shi <address@hidden> wrote:
> 
> > * Cornelia Huck <address@hidden> [2017-07-28 14:58:19 +0200]:
> 
> > > Exposing real channel paths to the guest means that the guest OS needs
> > > to be able to deal with path-related things, but OTOH it has more
> > > control. As I don't think we'll ever want to support a guest OS that
> > > does not also run under LPAR, I'd prefer that way.
> > >   
> > My poor English... Sorry, I don't undersatnd the last sentence...
> 
> Probably too many negations... let me rephrase.
Negations kill my brain. ;)

> 
> Looking at the guest OSes we want to support, it's currently Linux,
> Linux, or Linux. And Linux runs fine under LPAR, as it is able to deal
> with the details of channel path handling (and LPAR does not virtualize
> anything of this).
Nod.

> 
> Of the other OSes, z/OS is way too insanely complex, z/VM does not make
> much sense, and I don't see a case for z/TPF either. Which leaves
> z/VSE, which should be able to deal with the path related stuff as well.
Nod.

> 
> So, I don't think we close any doors if we expose the path handling
> complexities to the guest.
> 
Understand now! Thanks a lot!

-- 
Dong Jia Shi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]