From: Yosuke Iwamatsu <y-iwamatsu@ab.jp.nec.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH 0/3][RFC] PV Passthrough PCI Device Hotplug Support
Date: Thu, 21 Feb 2008 22:25:43 +0900 [thread overview]
Message-ID: <47BD7BD7.4020604@ab.jp.nec.com> (raw)
In-Reply-To: <C3E32400.1CC96%Keir.Fraser@cl.cam.ac.uk>
Keir Fraser wrote:
> I mean have an extra global node called e.g., reconfigure. Set to 1 when
> pciback has updated hotplug info, causes pcifront to set reconfigure back to
> 0 and then re-scan the xenstore directory. Would that work?
Understood. Perhaps I'll give it a try in that manner.
>
>> dev-# names are the physical names.
>> vdev-# becomes the same as dev-# when compiled with PCIDEV_BACKEND_PASS,
>> but different when compiled with other options (VPCI, SLOT).
>> vdev-# names are necessary for pcifront to recognize which devices are
>> to be detached.
>
> Why would pcifront need to know the physical name? I would think that dev-#
> should be the virtual name.
dev-#, vdev-# and state-# are all backend nodes.
Xend writes physical names on dev-# to let pciback know which device
should be exported (This is the original behaviour).
Then pciback publishes the corresponding virtul name on vdev-#.
At the time of detachment, pcifront scans backend nodes and finds
which device should be removed by seeing vdev-#.
pcifront doesn't need to know the physical name indeed.
----
Yosuke
>
> -- Keir
>
next prev parent reply other threads:[~2008-02-21 13:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-21 11:00 [PATCH 0/3][RFC] PV Passthrough PCI Device Hotplug Support Yosuke Iwamatsu
2008-02-21 11:09 ` Keir Fraser
2008-02-21 12:37 ` Yosuke Iwamatsu
2008-02-21 12:50 ` Keir Fraser
2008-02-21 13:25 ` Yosuke Iwamatsu [this message]
2008-02-21 13:45 ` Keir Fraser
2008-02-22 2:03 ` Yosuke Iwamatsu
2008-02-22 8:01 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47BD7BD7.4020604@ab.jp.nec.com \
--to=y-iwamatsu@ab.jp.nec.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.