Cell press release, redacted.
CASTalk.com Forum Index CASTalk.com
Discussion of DSP, FPGA, storage and embedded system.
 
 FAQFAQ   MemberlistMemberlist     RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Google
 
Web castalk.com
Cell press release, redacted.
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> Computer Architecture
Author Message
glen herrmannsfeldt
Guest
Posted: Thu Feb 10, 2005 12:52 am    Post subject: Re: intel's Vanderpool and virtualization in general Reply with quote
Anne & Lynn Wheeler wrote:

(big snip)

Quote:
so that has been running for something like a year. endicott engineers
finally claim that they have an 370/145 with engineering changes to
support virtual memory and it is ready for some testing.

some people go to endicott and install a cp67-i kernel and attempt to
boot ... and it fails. so some amount of investigation ... and it
turns out that the kernel is correct ... but the engineers had
reversed the implementation of the "B2" opcodes for PTLB (purge
lookaside table) and RRB (reset reference bit). so some quick patches
in a couple places ... and the kernel boots and runs fine. also
software designed to the architecture spec runs correctly in virtual
machines ... since the virtual machine emulation of the "B2" opcodes
conform to the official architecture ... it is only the real kernel
use of the functions that has been changed to conform to the real
machine.

So, do you use STIDP to decide which machine you are actually
running on and execute the appropriate opcodes depending on the
result?

-- glen
Back to top
David Magda
Guest
Posted: Thu Feb 10, 2005 1:39 am    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:

Quote:
On Wed, 09 Feb 2005 13:29:15 +0000, Nick Maclaren wrote:
[...]
Firstly, POSIX was and is primarily to define interfaces for
unprivileged applications, and secondarily to provide ones for
slightly privileged system utilities.

Yep. Pity it hasn't worked out (yet). Maybe java will get there
instead.

POSIX hasn't been a complete failure either. Most software compiles
fairly well across the various Unixes.

--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Back to top
Del Cecchi
Guest
Posted: Thu Feb 10, 2005 2:19 am    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
Eric P. wrote:
Quote:
Del Cecchi wrote:

If you go wander around IBM's web site, I am confident you will find
plenty of information about the virtues of virtualization. It seems to
be a key element of the Server Value Proposition. Or whatever.


Looking at

http://www-1.ibm.com/servers/eserver/about/virtualization/

it seems to be mostly concerned with systems management,
and remote management in particular.

These are functions I would prefer, and seem most natural,
located in the OS and accessable via APIs and thereby usable for
many purposes by value added and ISV developed applications.

Eric


There are many hits on www.ibm.com when you search for virtualization.

One advantage is that one can run many instances of an operating system
or systems on a single physical box. This allows server consolidation
for example. But if you have a PC/single user mindset then it can be
hard to realize the benefits of virtualization.

del cecchi
Back to top
Nick Maclaren
Guest
Posted: Thu Feb 10, 2005 2:33 am    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
In article <420a3606$0$28990$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
Quote:
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:

There's no reason why modern Windows shouldn't be able to support
Windows 98 (or earlier) applications, or for Solaris 10 to support Solaris
6 (or even SunOS-4) applications, since in both cases the companies own
all of the necessary library copyrights.

Solaris 10 does exactly that, but:

- ISVs are often not willing to support programs other than on
"certified" releases.

Why single out ISVs? Most vendors aren't willing to support much of
their software in more than a small proportion of combinations. It
is a nightmare for those of us who need to use specialised libraries
in conjunction with bleeding edge operating systems and compilers.

Quote:
- Their be dragons: even perfect compatibility will not allow
all programs to run because programs have bugs in them.
Some of those bugs proof fatal in new OS releases and are
impossible to fix.

And a pretty fair number of those programs are part of the system :-(

In my experience there is little difference in this aspect between
users' code, ISVs and the system vendor's products. ALL are buggy,
and ALL tend to assume more than the interface specifies. Now, my
heretical claim is that most of the fault should be lain at the door
of the goons who write the interface specifications, for the following
crimes:

Unreasonable ambiguity, obscurity and inconsistency

Negligence in investigating requirements and constraints

Failure to provide adequate facilities for real use

Note that I am NOT singling out things like POSIX here, but including
vendors' own calling and usage conventions. FAR too few organisations
(and people) realise that designing interface conventions is a serious
engineering task, and needs appropriate care, effort and skill.


Regards,
Nick Maclaren.
Back to top
Sander Vesik
Guest
Posted: Thu Feb 10, 2005 3:49 am    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
Casper H.S. Dik <Casper.Dik@sun.com> wrote:
Quote:

I think there's no large organization in the world that doesn't want
to get rid of the PC desktop which isn't under strict control.

Symantec for one doesn't - they'd get a large revenue drop if it happened ;-)

Quote:

Casper

--
Sander

+++ Out of cheese error +++
Back to top
Andrew Reilly
Guest
Posted: Thu Feb 10, 2005 4:22 am    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
On Wed, 09 Feb 2005 16:19:07 -0600, Del Cecchi wrote:
Quote:
There are many hits on www.ibm.com when you search for virtualization.
One advantage is that one can run many instances of an operating system
or systems on a single physical box. This allows server consolidation
for example.

This assumes that the operating system is so weak that it can only support
one application, and so you need to keep the
operating-system-instance/application-instance pairing that you were
forced into when you went to the one-application-per-box model. Not all
operating systems are so weak, and system administrators shouldn't be so
eager to treat them as just the library needed to provide the api to run
the application, exo-kernel style.

Oh, your applications use different OSes? Which ones? In the
Windows/Business universe, all applications are Windows applications.
Sure, in the Linux universe you might also want to run some Windows
applications, but does Intel really care enough about that niche to add
virtualization facilities to their processors?

Incidentally, how does virtualization on x86 processors square with the
coming DRM-down-to-the-hardware mechanisms? Aren't they inherently
incompatible?

--
Andrew
Back to top
Anne & Lynn Wheeler
Guest
Posted: Thu Feb 10, 2005 5:00 am    Post subject: Re: intel's Vanderpool and virtualization in general Reply with quote
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
Quote:
This assumes that the operating system is so weak that it can only
support one application, and so you need to keep the
operating-system-instance/application-instance pairing that you were
forced into when you went to the one-application-per-box model. Not
all operating systems are so weak, and system administrators
shouldn't be so eager to treat them as just the library needed to
provide the api to run the application, exo-kernel style.

Oh, your applications use different OSes? Which ones? In the
Windows/Business universe, all applications are Windows applications.
Sure, in the Linux universe you might also want to run some Windows
applications, but does Intel really care enough about that niche to add
virtualization facilities to their processors?

Incidentally, how does virtualization on x86 processors square with the
coming DRM-down-to-the-hardware mechanisms? Aren't they inherently
incompatible?

from what i've seen it isn't so much an technical operating system
issue, it is an infrastructure administrative management issue; the
systems have gotten so big providing support for huge numbers of
different applications ... that when any administrative activity needs
to take place ... it has become impossible to (administratively)
coordinate everything. It appears to be much more of a people problem
than a technical issue. Being able to partition ... say by business
divisions ... means that administrative coordination only has to occur
at the business division level instead of across the whole enterprise
(say syncronizing tens of thousands of interests rather than large
hundreds of thousands of interests).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Back to top
Terje Mathisen
Guest
Posted: Thu Feb 10, 2005 12:58 pm    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
Nick Maclaren wrote:
Quote:
In article <pan.2005.02.08.23.55.39.59408@areilly.bpc-users.org>,
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
|> Didn't the PC revolution do away with that time-sharing model anyway, and
|> give all users root access of the box that they were using?

(This being Andrew, I had no problem seeing the implied emoticon.)
Quote:

Are you serious, or trolling? Obviously not, except in the hacker
community.

Effectively all Windows machines still run with user == Admin.

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Back to top
Casper H.S. Dik
Guest
Posted: Thu Feb 10, 2005 5:36 pm    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Quote:
Why single out ISVs? Most vendors aren't willing to support much of
their software in more than a small proportion of combinations. It
is a nightmare for those of us who need to use specialised libraries
in conjunction with bleeding edge operating systems and compilers.

I used this as a generic term for "software producers"; not sure
how else I would put that. I'm sure we offend against our own
rules also.

Quote:
- Their be dragons: even perfect compatibility will not allow
all programs to run because programs have bugs in them.
Some of those bugs proof fatal in new OS releases and are
impossible to fix.

And a pretty fair number of those programs are part of the system :-(

The programs which are part of the system are exempt from the rules;
the assumption is they are tested and fixed as part of the OS
release cycle.

Quote:
In my experience there is little difference in this aspect between
users' code, ISVs and the system vendor's products. ALL are buggy,
and ALL tend to assume more than the interface specifies. Now, my
heretical claim is that most of the fault should be lain at the door
of the goons who write the interface specifications, for the following
crimes:

Unreasonable ambiguity, obscurity and inconsistency

Negligence in investigating requirements and constraints

Failure to provide adequate facilities for real use

Note that I am NOT singling out things like POSIX here, but including
vendors' own calling and usage conventions. FAR too few organisations
(and people) realise that designing interface conventions is a serious
engineering task, and needs appropriate care, effort and skill.

It's not just the specification, it's also the implementation.
Implementations should be *unforgiving*. When it says that some
fields are "reserved, must be zero"; the interface must fail if that
is not the case.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Back to top
Nick Maclaren
Guest
Posted: Thu Feb 10, 2005 5:53 pm    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
In article <420b554a$0$28986$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
|> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|>
|> >Why single out ISVs? Most vendors aren't willing to support much of
|> >their software in more than a small proportion of combinations. It
|> >is a nightmare for those of us who need to use specialised libraries
|> >in conjunction with bleeding edge operating systems and compilers.
|>
|> I used this as a generic term for "software producers"; not sure
|> how else I would put that. I'm sure we offend against our own
|> rules also.

You do. So do AAA, BBB, CC, DDDDD and EEEEEEEEE at least. I have
no close contacts with the others. Names changed to protect the
guilty :-)

|> The programs which are part of the system are exempt from the rules;
|> the assumption is they are tested and fixed as part of the OS
|> release cycle.

And the assumption of the legal system in most countries is that
no reasonable person ever breaks the law. Both assumptions are
about equally realistic. There are just so many optional components,
configuration options and so on that - even with the best will in
the world - testing all interactions just ain't feasible.

As you would expect, 90% of the compatibility problems I see are
associated with 'unusual but nominally supported' combinations of
components and options. This applies to all vendors.

|> It's not just the specification, it's also the implementation.
|> Implementations should be *unforgiving*. When it says that some
|> fields are "reserved, must be zero"; the interface must fail if that
|> is not the case.

I agree with that - and implementation sloppiness used to be the
cause of the majority of incompatibilities. In my experience, those
happy days are long gone, and incompatibilities are now dominated by
problems caused by the deficiences in specifications that I mentioned.


Regards,
Nick Maclaren.
Back to top
Del Cecchi
Guest
Posted: Thu Feb 10, 2005 8:35 pm    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
Andrew Reilly wrote:
Quote:
On Wed, 09 Feb 2005 16:19:07 -0600, Del Cecchi wrote:

There are many hits on www.ibm.com when you search for virtualization.
One advantage is that one can run many instances of an operating system
or systems on a single physical box. This allows server consolidation
for example.


This assumes that the operating system is so weak that it can only support
one application, and so you need to keep the
operating-system-instance/application-instance pairing that you were
forced into when you went to the one-application-per-box model. Not all
operating systems are so weak, and system administrators shouldn't be so
eager to treat them as just the library needed to provide the api to run
the application, exo-kernel style.

Oh, your applications use different OSes? Which ones? In the
Windows/Business universe, all applications are Windows applications.
Sure, in the Linux universe you might also want to run some Windows
applications, but does Intel really care enough about that niche to add
virtualization facilities to their processors?

Incidentally, how does virtualization on x86 processors square with the
coming DRM-down-to-the-hardware mechanisms? Aren't they inherently
incompatible?

I give up. You win. Virtualization is totally un necessary. Windows

is the answer. The X86 on a desktop is all anyone needs. Have a nice
life.

del cecchi
Back to top
mike
Guest
Posted: Thu Feb 10, 2005 8:41 pm    Post subject: Re: intel's Vanderpool and virtualization in general (was Re Reply with quote
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:cuflfj$5tu$1@gemini.csx.cam.ac.uk...
Quote:

In article <420b554a$0$28986$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
|> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|
|> >Why single out ISVs? Most vendors aren't willing to support much of
|> >their software in more than a small proportion of combinations. It
|> >is a nightmare for those of us who need to use specialised libraries
|> >in conjunction with bleeding edge operating systems and compilers.
|
|> I used this as a generic term for "software producers"; not sure
|> how else I would put that. I'm sure we offend against our own
|> rules also.

You do. So do AAA, BBB, CC, DDDDD and EEEEEEEEE at least. I have
no close contacts with the others. Names changed to protect the
guilty :-)

|> The programs which are part of the system are exempt from the rules;
|> the assumption is they are tested and fixed as part of the OS
|> release cycle.

And the assumption of the legal system in most countries is that
no reasonable person ever breaks the law. Both assumptions are
about equally realistic. There are just so many optional components,
configuration options and so on that - even with the best will in
the world - testing all interactions just ain't feasible.

As you would expect, 90% of the compatibility problems I see are
associated with 'unusual but nominally supported' combinations of
components and options. This applies to all vendors.

|> It's not just the specification, it's also the implementation.
|> Implementations should be *unforgiving*. When it says that some
|> fields are "reserved, must be zero"; the interface must fail if that
|> is not the case.

I agree with that - and implementation sloppiness used to be the
cause of the majority of incompatibilities. In my experience, those
happy days are long gone, and incompatibilities are now dominated by
problems caused by the deficiences in specifications that I mentioned.


Regards,
Nick Maclaren.

I agree, and that is about the best justification I have seen for extreme
microkernel designs like GNU HURD with almost all OS services in user land.
Fewer, better architected interactions between components, easier to debug,
restart failed services, etc.

The problem, is that increased context changes reduce performance. This
disadvantage may finally be ameliorated with better CPU architectures and
many cores on a die.

In future years we may see a merging of VM technology and OS technology into
a HURD like design that also provides multiple OS "personalities" and
support for multiple OS versions along the lines of the failed IBM Workplace
OS and Fort Knox.

Mike Sicilian
Back to top
Anne & Lynn Wheeler
Guest
Posted: Thu Feb 10, 2005 9:48 pm    Post subject: Re: intel's Vanderpool and virtualization in general Reply with quote
"mike" <mike@mike.net> writes:
Quote:
I agree, and that is about the best justification I have seen for
extreme microkernel designs like GNU HURD with almost all OS
services in user land. Fewer, better architected interactions
between components, easier to debug, restart failed services, etc.

The problem, is that increased context changes reduce performance.
This disadvantage may finally be ameliorated with better CPU
architectures and many cores on a die.

In future years we may see a merging of VM technology and OS
technology into a HURD like design that also provides multiple OS
"personalities" and support for multiple OS versions along the lines
of the failed IBM Workplace OS and Fort Knox.

there are possibly two separate issues ...

1) using simplified interface for improved (and checkable)
partitioning and isolation (where things are really totally unrelated)
and

2) using simplified interface for improved (and checkable) partitioning
and isolation (where things may require interaction).

in the later case, MVS sort of backed into this when they started
hitting the 16mbyte addressing limit and extensive dependance on
pointer-passing paradigm.

OS/VS2-SVS was essentially the real stoarge MVT kernel laid out in a
(single) 16mbyte virtual address space. The transition to OS/VS2-MVS
involved giving each application their own address space ... but with
the kernel image occupying 8mbytes of each 16mbyte virtual address
space. This moved some number of "services" that weren't in the kernel
into different virtual address spaces than the applications for which
they were suppose to provide services for.

This gave rise to dual-address support with the 3033 (allowing the
"service" to use pointers that pointed into an application address
space) ... however, you still needed to do a kernel call to switch
from the application address space to the service address space.

Wtih the evolution of architecture, there was also introduction of
stuff like "access registers" and *program-call*.

Basically *program-call* was a branch-and-link type library call
.... but was supported by a kernel-based access/privileges table
(analogous to kernel-based virtual memory tables that support virtual
address spaces). Basically the *program-call* instruction could
reference the access/privilege table (in mannter analogous to virtual
addresses being resolved by accessing kernel-based virtual memory
tables) to resolve the *program-call*.

The hardware then handles both virtual address space and context
switching w/o requiring kernel processing via kernel call (making
*program-call* almost as fast as a branch-and-link operation).

So the claim was that the 3033 with dual-address space support started
to see more TLB misses because of the increase in the total different
virtual address spaces ... aka TLB entries were virtual address space
associative, with a STO-stack ... where "STO" equates to unique
virtual address space. Transition to dual-address space support had a
hit on the size of the STO-stack needed (because of the increase in
unique virtual address spaces needed to perform an operation).

So with *program-call*, it had eliminated the kernel call for context
and address space switch. The total cache-line hit was about the same
as with the straight branch-and-link subroutine call paradigm (with
everything within the same address space) ... since the amount of code
was effectively the same (modulo that the *program-call* instruction
had to reference the kernel access/privilege table). The number of the
TLB entries were about the same since the amount of code was still
about the same. The biggest hit was on the STO-stack table (number of
concurrent different/unique virtual address spaces that TLB could keep
track of).

*program-call* description
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.26?SHELF=EZ2HW125&DT=19970613131822

access register discussion
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/E.1.1?SHELF=EZ2HW125&DT=19970613131822

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Back to top
Nick Maclaren
Guest
Posted: Thu Feb 10, 2005 9:56 pm    Post subject: Re: intel's Vanderpool and virtualization in general Reply with quote
In article <m31xboe4z7.fsf@lhwlinux.garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> writes:
|>
|> in the later case, MVS sort of backed into this when they started
|> hitting the 16mbyte addressing limit and extensive dependance on
|> pointer-passing paradigm.

I am reminded of the story (from the days of the Raj) about the
elephant that backed into a stacked pile of rifles - complete
with fixed bayonets.

Quite. And 90% of the problems there were due to looseness in
the specifications about what the top might must or might contain,
with different components making different assumptions.


Regards,
Nick Maclaren.
Back to top
mike
Guest
Posted: Thu Feb 10, 2005 10:12 pm    Post subject: Re: intel's Vanderpool and virtualization in general Reply with quote
"Anne & Lynn Wheeler" <lynn@garlic.com> wrote in message
news:m31xboe4z7.fsf@lhwlinux.garlic.com...
Quote:
"mike" <mike@mike.net> writes:
I agree, and that is about the best justification I have seen for
extreme microkernel designs like GNU HURD with almost all OS
services in user land. Fewer, better architected interactions
between components, easier to debug, restart failed services, etc.

The problem, is that increased context changes reduce performance.
This disadvantage may finally be ameliorated with better CPU
architectures and many cores on a die.

In future years we may see a merging of VM technology and OS
technology into a HURD like design that also provides multiple OS
"personalities" and support for multiple OS versions along the lines
of the failed IBM Workplace OS and Fort Knox.

there are possibly two separate issues ...

1) using simplified interface for improved (and checkable)
partitioning and isolation (where things are really totally unrelated)
and

2) using simplified interface for improved (and checkable) partitioning
and isolation (where things may require interaction).

in the later case, MVS sort of backed into this when they started
hitting the 16mbyte addressing limit and extensive dependance on
pointer-passing paradigm.

OS/VS2-SVS was essentially the real stoarge MVT kernel laid out in a
(single) 16mbyte virtual address space. The transition to OS/VS2-MVS
involved giving each application their own address space ... but with
the kernel image occupying 8mbytes of each 16mbyte virtual address
space. This moved some number of "services" that weren't in the kernel
into different virtual address spaces than the applications for which
they were suppose to provide services for.

This gave rise to dual-address support with the 3033 (allowing the
"service" to use pointers that pointed into an application address
space) ... however, you still needed to do a kernel call to switch
from the application address space to the service address space.

Wtih the evolution of architecture, there was also introduction of
stuff like "access registers" and *program-call*.

Basically *program-call* was a branch-and-link type library call
... but was supported by a kernel-based access/privileges table
(analogous to kernel-based virtual memory tables that support virtual
address spaces). Basically the *program-call* instruction could
reference the access/privilege table (in mannter analogous to virtual
addresses being resolved by accessing kernel-based virtual memory
tables) to resolve the *program-call*.

The hardware then handles both virtual address space and context
switching w/o requiring kernel processing via kernel call (making
*program-call* almost as fast as a branch-and-link operation).

So the claim was that the 3033 with dual-address space support started
to see more TLB misses because of the increase in the total different
virtual address spaces ... aka TLB entries were virtual address space
associative, with a STO-stack ... where "STO" equates to unique
virtual address space. Transition to dual-address space support had a
hit on the size of the STO-stack needed (because of the increase in
unique virtual address spaces needed to perform an operation).

So with *program-call*, it had eliminated the kernel call for context
and address space switch. The total cache-line hit was about the same
as with the straight branch-and-link subroutine call paradigm (with
everything within the same address space) ... since the amount of code
was effectively the same (modulo that the *program-call* instruction
had to reference the kernel access/privilege table). The number of the
TLB entries were about the same since the amount of code was still
about the same. The biggest hit was on the STO-stack table (number of
concurrent different/unique virtual address spaces that TLB could keep
track of).

*program-call* description
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.26?SHELF=EZ2HW125&DT=19970613131822

access register discussion
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/E.1.1?SHELF=EZ2HW125&DT=19970613131822

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

I did not realize that MVS and /370 were so efficient at context switching.
This is a famous problem with HURD. It sounds like the HURD developers
should copy the IBM solution.

It would be an interesting research project to look at combining this
context switch technology with the 'hypervisor" and LPAR technology on both
Z and P hardware to share resources across VM's.

Mike Sicilian
Back to top
 
Post new topic   Reply to topic    CASTalk.com Forum Index -> Computer Architecture All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 4 of 6

 
 You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




VoIP Electronics Powered by phpBB