hvcs.txt

linux 内核源代码

fetch the data.

Additionally, disconnecting a vty-server and vty only on module removal or
adapter removal is impractical because other vty-servers in other
partitions may require the usage of the target vty at any time.

Due to this behavioral restriction disconnection of vty-servers from the
connected vty is a manual procedure using a write to a sysfs attribute
outlined below, on the other hand the initial vty-server connection to a
vty is established automatically by this driver.  Manual vty-server
connection is never required.

In order to terminate the connection between a vty-server and vty the
"vterm_state" sysfs attribute within each vty-server's sysfs entry is used.
Reading this attribute reveals the current connection state of the
vty-server adapter.  A zero means that the vty-server is not connected to a
vty.  A one indicates that a connection is active.

Writing a '0' (zero) to the vterm_state attribute will disconnect the VTERM
connection between the vty-server and target vty ONLY if the vterm_state
previously read '1'.  The write directive is ignored if the vterm_state
read '0' or if any value other than '0' was written to the vterm_state
attribute.  The following example will show the method used for verifying
the vty-server connection status and disconnecting a vty-server connection.

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
	1

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo 0 > vterm_state

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
	0

All vty-server connections are automatically terminated when the device is
hotplug removed and when the module is removed.

---------------------------------------------------------------------------
7. Configuration

Each vty-server has a sysfs entry in the /sys/devices/vio directory, which
is symlinked in several other sysfs tree directories, notably under the
hvcs driver entry, which looks like the following example:

	Pow5:/sys/bus/vio/drivers/hvcs # ls
	.  ..  30000003  30000004  rescan

By design, firmware notifies the hvcs driver of vty-server lifetimes and
partner vty removals but not the addition of partner vtys.  Since an HMC
Super Admin can add partner info dynamically we have provided the hvcs
driver sysfs directory with the "rescan" update attribute which will query
firmware and update the partner info for all the vty-servers that this
driver manages.  Writing a '1' to the attribute triggers the update.  An
explicit example follows:

	Pow5:/sys/bus/vio/drivers/hvcs # echo 1 > rescan

Reading the attribute will indicate a state of '1' or '0'.  A one indicates
that an update is in process.  A zero indicates that an update has
completed or was never executed.

Vty-server entries in this directory are a 32 bit partition unique unit
address that is created by firmware.  An example vty-server sysfs entry
looks like the following:

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls
	.   current_vty   devspec       name          partner_vtys
	..  index         partner_clcs  vterm_state

Each entry is provided, by default with a "name" attribute.  Reading the
"name" attribute will reveal the device type as shown in the following
example:

	Pow5:/sys/bus/vio/drivers/hvcs/30000003 # cat name
	vty-server

Each entry is also provided, by default, with a "devspec" attribute which
reveals the full device specification when read, as shown in the following
example:

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat devspec
	/vdevice/vty-server@30000004

Each vty-server sysfs dir is provided with two read-only attributes that
provide lists of easily parsed partner vty data: "partner_vtys" and
"partner_clcs".

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_vtys
	30000000
	30000001
	30000002
	30000000
	30000000

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_clcs
	U5112.428.103048A-V3-C0
	U5112.428.103048A-V3-C2
	U5112.428.103048A-V3-C3
	U5112.428.103048A-V4-C0
	U5112.428.103048A-V5-C0

Reading partner_vtys returns a list of partner vtys.  Vty unit address
numbering is only per-partition-unique so entries will frequently repeat.

Reading partner_clcs returns a list of "converged location codes" which are
composed of a system serial number followed by "-V*", where the '*' is the
target partition number, and "-C*", where the '*' is the slot of the
adapter.  The first vty partner corresponds to the first clc item, the
second vty partner to the second clc item, etc.

A vty-server can only be connected to a single vty at a time.  The entry,
"current_vty" prints the clc of the currently selected partner vty when
read.

The current_vty can be changed by writing a valid partner clc to the entry
as in the following example:

	Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo U5112.428.10304
	8A-V4-C0 > current_vty

Changing the current_vty when a vty-server is already connected to a vty
does not affect the current connection.  The change takes effect when the
currently open connection is freed.

Information on the "vterm_state" attribute was covered earlier on the
chapter entitled "disconnection".

---------------------------------------------------------------------------
8. Questions & Answers:
===========================================================================
Q: What are the security concerns involving hvcs?

A: There are three main security concerns:

	1. The creator of the /dev/hvcs* nodes has the ability to restrict
	the access of the device entries to certain users or groups.  It
	may be best to create a special hvcs group privilege for providing
	access to system consoles.

	2. To provide network security when grabbing the console it is
	suggested that the user connect to the console hosting partition
	using a secure method, such as SSH or sit at a hardware console.

	3. Make sure to exit the user session when done with a console or
	the next vty-server connection (which may be from another
	partition) will experience the previously logged in session.

---------------------------------------------------------------------------
Q: How do I multiplex a console that I grab through hvcs so that other
people can see it:

A: You can use "screen" to directly connect to the /dev/hvcs* device and
setup a session on your machine with the console group privileges.  As
pointed out earlier by default screen doesn't provide the termcap settings
for most terminal emulators to provide adequate character conversion from
term type "screen" to others.  This means that curses based programs may
not display properly in screen sessions.

---------------------------------------------------------------------------
Q: Why are the colors all messed up?
Q: Why are the control characters acting strange or not working?
Q: Why is the console output all strange and unintelligible?

A: Please see the preceding section on "Connection" for a discussion of how
applications can affect the display of character control sequences.
Additionally, just because you logged into the console using and xterm
doesn't mean someone else didn't log into the console with the HMC console
(vt320) before you and leave the session logged in.  The best thing to do
is to export TERM to the terminal type of your terminal emulator when you
get the console.  Additionally make sure to "exit" the console before you
disconnect from the console.  This will ensure that the next user gets
their own TERM type set when they login.

---------------------------------------------------------------------------
Q: When I try to CONNECT kermit to an hvcs device I get:
"Sorry, can't open connection: /dev/hvcs*"What is happening?

A: Some other Power5 console mechanism has a connection to the vty and
isn't giving it up.  You can try to force disconnect the consoles from the
HMC by right clicking on the partition and then selecting "close terminal".
Otherwise you have to hunt down the people who have console authority.  It
is possible that you already have the console open using another kermit
session and just forgot about it.  Please review the console options for
Power5 systems to determine the many ways a system console can be held.

OR

A: Another user may not have a connectivity method currently attached to a
/dev/hvcs device but the vterm_state may reveal that they still have the
vty-server connection established.  They need to free this using the method
outlined in the section on "Disconnection" in order for others to connect
to the target vty.

OR

A: The user profile you are using to execute kermit probably doesn't have
permissions to use the /dev/hvcs* device.

OR

A: You probably haven't inserted the hvcs.ko module yet but the /dev/hvcs*
entry still exists (on systems without udev).

OR

A: There is not a corresponding vty-server device that maps to an existing
/dev/hvcs* entry.

---------------------------------------------------------------------------
Q: When I try to CONNECT kermit to an hvcs device I get:
"Sorry, write access to UUCP lockfile directory denied."

A: The /dev/hvcs* entry you have specified doesn't exist where you said it
does?  Maybe you haven't inserted the module (on systems with udev).

---------------------------------------------------------------------------
Q: If I already have one Linux partition installed can I use hvcs on said
partition to provide the console for the install of a second Linux
partition?

A: Yes granted that your are connected to the /dev/hvcs* device using
kermit or cu or some other program that doesn't provide terminal emulation.

---------------------------------------------------------------------------
Q: Can I connect to more than one partition's console at a time using this
driver?

A: Yes.  Of course this means that there must be more than one vty-server
configured for this partition and each must point to a disconnected vty.

---------------------------------------------------------------------------
Q: Does the hvcs driver support dynamic (hotplug) addition of devices?

A: Yes, if you have dlpar and hotplug enabled for your system and it has
been built into the kernel the hvcs drivers is configured to dynamically
handle additions of new devices and removals of unused devices.

---------------------------------------------------------------------------
Q: For some reason /dev/hvcs* doesn't map to the same vty-server adapter
after a reboot.  What happened?

A: Assignment of vty-server adapters to /dev/hvcs* entries is always done
in the order that the adapters are exposed.  Due to hotplug capabilities of
this driver assignment of hotplug added vty-servers may be in a different
order than how they would be exposed on module load.  Rebooting or
reloading the module after dynamic addition may result in the /dev/hvcs*
and vty-server coupling changing if a vty-server adapter was added in a
slot inbetween two other vty-server adapters.  Refer to the section above
on how to determine which vty-server goes with which /dev/hvcs* node.
Hint; look at the sysfs "index" attribute for the vty-server.

---------------------------------------------------------------------------
Q: Can I use /dev/hvcs* as a conduit to another partition and use a tty
device on that partition as the other end of the pipe?

A: Yes, on Power5 platforms the hvc_console driver provides a tty interface
for extra /dev/hvc* devices (where /dev/hvc0 is most likely the console).
In order to get a tty conduit working between the two partitions the HMC
Super Admin must create an additional "serial server" for the target
partition with the HMC gui which will show up as /dev/hvc* when the target
partition is rebooted.

The HMC Super Admin then creates an additional "serial client" for the
current partition and points this at the target partition's newly created
"serial server" adapter (remember the slot).  This shows up as an
additional /dev/hvcs* device.

Now a program on the target system can be configured to read or write to
/dev/hvc* and another program on the current partition can be configured to
read or write to /dev/hvcs*.  Now you have a tty conduit between two
partitions.

---------------------------------------------------------------------------
9. Reporting Bugs:

The proper channel for reporting bugs is either through the Linux OS
distribution company that provided your OS or by posting issues to the
PowerPC development mailing list at:

[e-mail]

This request is to provide a documented and searchable public exchange
of the problems and solutions surrounding this driver for the benefit of
all users.