Browse Prior Art Database

Trace Entry Verification Count

IP.com Disclosure Number: IPCOM000040315D
Original Publication Date: 1987-Oct-01
Included in the Prior Art Database: 2005-Feb-02
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Ku, KS: AUTHOR [+2]

Abstract

In a VM/SP operating system, if one has a trace table shared by a number of virtual machines, one needs to insure that entries in the table are valid. The trace table can be put in an area of storage that is shared by all virtual machines that are members of a particular "group". Each trace table entry must include a "header", which identifies the type event causing the trace entry, the length of the trace entry, time and date information, virtual machine identification, and a "Trace Entry Verification Count" (TEVC). When the trace table is full, it "wraps" and is reused from the beginning. The method of allocating "slots" for trace table entries, and the nature of virtual machines in general, allows one virtual machine to reserve a slot for a trace entry and then be interrupted before putting the trace entry into that slot.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Trace Entry Verification Count

In a VM/SP operating system, if one has a trace table shared by a number of virtual machines, one needs to insure that entries in the table are valid. The trace table can be put in an area of storage that is shared by all virtual machines that are members of a particular "group". Each trace table entry must include a "header", which identifies the type event causing the trace entry, the length of the trace entry, time and date information, virtual machine identification, and a "Trace Entry Verification Count" (TEVC). When the trace table is full, it "wraps" and is reused from the beginning.

The method of allocating "slots" for trace table entries, and the nature of virtual machines in general, allows one virtual machine to reserve a slot for a trace entry and then be interrupted before putting the trace entry into that slot. This allows another virtual machine to reserve and build a trace entry, before the first machine regains control to build its trace entry. When the first machine is dispatched, and builds its trace entry, the time stamps will be out of sequence with the subsequent entry. This is not an uncommon happening. If a dump of the trace table is taken after the second machine has built its trace entry and before the first machine has been dispatched, the reserved but unused slot contains invalid data. This entry may otherwise appear to be valid, as in the case of a reserved slot exactly overlaying a slot from a previous "wrap" of the trace table. Or this entry may obviously be invalid, as in the case of a reserved slot beginning in the middle of a user trace entry from a previous wrap of the trace table. A method is needed to identify this situation. The TEVC is essentially a "wrap count" through the trace table. For any three consecutive valid entries (not at the extreme ends of the table, and not near where new entries are being written) the first entry will have a particular value for the TEVC.

Using the length of this first entry, the second entry can be located and should have the same TEVC. With the length of the second entry obtained, the third trace table entry can be found, which should again have the same TEVC. If the second slot has been reserved, and not yet used, the TEVC for th...