[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3] Channel Path realted CRW generation
From: |
Dong Jia Shi |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] Channel Path realted CRW generation |
Date: |
Tue, 1 Aug 2017 10:12:31 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
* Cornelia Huck <address@hidden> [2017-07-31 10:54:47 +0200]:
> On Fri, 28 Jul 2017 23:50:48 +0800
> Dong Jia Shi <address@hidden> wrote:
>
> > * Cornelia Huck <address@hidden> [2017-07-28 13:53:01 +0200]:
>
> > > > > You're bound to get different kinds of notifications: via a CRW with
> > > > > source channel path, via event information retrievable via CHSC
> > > > > (indicated by a CRW with source CSS),
> > > > Ha, I was not awre of this one before!
> > >
> > > That's the 'link incident' and 'resource accessibility' stuff.
> > My focus was trying to have the minimum stuff to make a Linux guest
> > working well -- basically, my working on prototype targeted to make the
> > output lschp and lscss corect and uptodate. I
> >
> > I will dig this and see if I need to do more stuff.
>
> You can probably skip this for now, unless you want to propagate the
> ficon-related stuff.
I don't even want to know about that now. ;)
> Just plain channel-path related changes should already cover the
> interesting stuff.
>
> > > > My prototype work tries to sync the belowing information from host
> > > > kernel to qemu:
> > > > 1. the real SCHIB, so stsch from guest could get the updated path
> > > > masks.
> > >
> > > How far do you want to go with mirroring? I think you need to modify at
> > > least the devno in the pmcw, no?
> > I didn't think this very deep. For now, I only sync the PIM, POM, PAM
> > and CHPIDs lazily.
>
> Also consider the pno bit and the pnom.
Roger!
>
> > For devno... I need to think more. If the qemu command has a given
> > "devno" for the vfio-ccw device, maybe we should not override its dev_id
> > with the real one "device number".
>
> The guest should not be surprised by a different devno, so you need to
> be sure everything is consistent.
Ok. Will handle the device number.
>
>
> > > > 3. still working on support CHSC store channel path description
> > > > command.
> > >
> > > I'm currently wondering how many of those chscs are optional. OTOH, if
> > > a modern Linux guest cannot work properly without them, it makes no
> > > sense to leave them out.
> > Nod.
> >
> > But I think I need to define the criteria for "work properly". For
> > example, with the current code, a Linux guest with a passed through
> > device works, while lschp shows the Cfg. as 3 (not recognized), and the
> > Shared and PCHID as "-". For this case, do you think it "work properly"?
>
> It depends upon what you want to expose to the guest. Some
> configuration checking or management tools might be reporting a
> configuration deficiency (*might*, I do not know).
This is helpful.
>
> Shared and PGID may be useful if the operator wants to perform some
> maintenance on the hardware (so they can figure out which systems/disks
> are affected), but the information should be available in the
> hypervisor as well, so I'm not sure whether it's a big deal.
>
Oh! This information is also very helpful.
Since I only want to expose the minimum information that the guest needs
to work without serious problem. I think I can also deffer these stuff
until we have the good chp modelling.
--
Dong Jia Shi
Re: [Qemu-devel] [PATCH 0/3] Channel Path realted CRW generation, Cornelia Huck, 2017/07/27