Xen devel - May 2005 - ia64/Xen VT-i support code is in Xen staging tree

Forward this to a broader mailing list.

VT-i is the virtual machine hardware feature for ia64.  With VT-i, we
can now successfully boot unmodified Linux-2.6.11 with ia64/Xen.   The
next step is to boot unmodified DomainN, and with the goal to support
both unmodified and paravirtualized Domains.

-Fred


==============Dan,

We have pushed our latest ia64/Xen code with VT support logic onto 

http://xen-ia64.bkbits.net:8080/xeno-unstable-ia64-staging.bk 

The tree is based on xeno-unstable-ia64.bk dated 4/24.  The current
status for ia64/Xen with VT support is we can boot unmodified
Linux2.6.11 as Domain0 to run both X and NIC.

You can do the following to build Xen with VT enabled once bk cloned

cd xen
sh arch/ia64/tools/mkbuildtree
make -j4

There is also a simple readme in README.RunVT.  

We are in process of rebase to the latest code, and will start merging
both paravirtualization and VT designs base on our previous email
threads.

-Fred



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Fred,

Are there any design documents publicly available regarding your strategy?  
How are you planning to implement device virtualisation on IPF?

Cheers,
Mark

On Tuesday 10 May 2005 14:54, Yang, Fred wrote:
> Forward this to a broader mailing list.
>
> VT-i is the virtual machine hardware feature for ia64.  With VT-i, we
> can now successfully boot unmodified Linux-2.6.11 with ia64/Xen.   The
> next step is to boot unmodified DomainN, and with the goal to support
> both unmodified and paravirtualized Domains.
>
> -Fred
>
>
> ==============> Dan,
>
> We have pushed our latest ia64/Xen code with VT support logic onto
>
> http://xen-ia64.bkbits.net:8080/xeno-unstable-ia64-staging.bk
>
> The tree is based on xeno-unstable-ia64.bk dated 4/24.  The current
> status for ia64/Xen with VT support is we can boot unmodified
> Linux2.6.11 as Domain0 to run both X and NIC.
>
> You can do the following to build Xen with VT enabled once bk cloned
>
> cd xen
> sh arch/ia64/tools/mkbuildtree
> make -j4
>
> There is also a simple readme in README.RunVT.
>
> We are in process of rebase to the latest code, and will start merging
> both paravirtualization and VT designs base on our previous email
> threads.
>
> -Fred
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Mark,
Our design strategy is to reuse ia32/Xen VMX design as possible.  That
is,
Device Model, the same DM in ia32 VMX, runs on Domain0 to service IO
requrests coming from VT DomainN.  We need to build Event Channel as
host driver runs in Domain0; we will borrow design from VBD of ia32 VMX
DomainN.  We also need to build corresponding hypercalls.
We also have guest firmware implemented to service DomainN boot/runtime
services.
-Fred
Mark Williamson wrote:
> Are there any design documents publicly available regarding your
> strategy? How are you planning to implement device virtualisation on
> IPF? 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Our design strategy is to reuse ia32/Xen VMX design as possible.  That
> is,
> Device Model, the same DM in ia32 VMX, runs on Domain0 to service IO
> requrests coming from VT DomainN.
OK.  Is there an existing codebase you can use to emulate common IPF system 
devices (where for VT-x, the Bochs / QEmu device models are being used) or 
will you be writing this stuff from scatch?
> We need to build Event Channel as 
> host driver runs in Domain0; we will borrow design from VBD of ia32 VMX
> DomainN.  We also need to build corresponding hypercalls.
> We also have guest firmware implemented to service DomainN boot/runtime
> services.
OK, that all makes sense - thanks.

Cheers,
Mark
> -Fred
>
> Mark Williamson wrote:
> > Are there any design documents publicly available regarding your
> > strategy? How are you planning to implement device virtualisation on
> > IPF?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Mark Williamson wrote:
> OK.  Is there an existing codebase you can use to emulate common IPF
> system devices (where for VT-x, the Bochs / QEmu device models are
> being used) or will you be writing this stuff from scatch?
We are using the exact same DM as VT-x, either Bochs/Qemu.  DM will be
64bit ready when we doing DomainN bringup.  So, we don''t do from
scratch
rather to reuse the code.
-Fred

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Mark Williamson wrote:
>>Our design strategy is to reuse ia32/Xen VMX design as possible.  That
>>is,
>>Device Model, the same DM in ia32 VMX, runs on Domain0 to service IO
>>requrests coming from VT DomainN.
> 
> 
> OK.  Is there an existing codebase you can use to emulate common IPF system
> devices (where for VT-x, the Bochs / QEmu device models are being used) or 
> will you be writing this stuff from scatch?
The plan is to reuse QEMU.

	-Arun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Mark Williamson wrote:
> > OK.  Is there an existing codebase you can use to emulate common IPF
> > system devices (where for VT-x, the Bochs / QEmu device models are
> > being used) or will you be writing this stuff from scatch?
>
> We are using the exact same DM as VT-x, either Bochs/Qemu.  DM will be
> 64bit ready when we doing DomainN bringup.  So, we don''t do from
scratch
> rather to reuse the code.
> -Fred
OK, I''d assumed that you''d need some different models to
behave like a
"typical" IPF system.  I guess as long as the common OSes support a
decent
range of hardware (as Linux does) it''s not a problem...  Do they all
have
IA-64 drivers for the (comparatively low end) hardware that Bochs / QEmu 
emulates?

Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

To whom it may concern

I am a third year Computer Science major at Williams College in
Williamstown, Massachusetts looking into thesis work to complete the
honors program for my degree.

To fulfill the requirements for this program, I am required to perform
independent research during the fall semester of next year leading into a
Senior Thesis during our January term and the spring semester of 2006.

I''m currently hoping to do research into virtual machines, first by
acquainting myself with virtualization techniques in general, and then by
trying to focus in on modern projects, of which Xen seems to be ideal,
given its open source nature and the recent attention it has gotten from a
number of sources.

Once this is done, for my thesis I would like to attempt to either extend
the functionality of Xen, or use Xen in a way that is of interest to the
virtualization community.

I am e-mailing this list because I am hoping to get the input of the Xen
developers on current long term projects within Xen or using Xen that
would be appropriate for this kind of project (approximately 4 1/2 months
of work, after research is complete, carrying an otherwise full
course load).

Essentially, I am hoping for answers to the following questions:

1) What additional functionality is being considered on the time scale
I''m
looking at? Of course, I assume that most of the projects on the Xen 3.0
roadmap are being incorporated into the next release of Xen this summer,
so work on most of these projects would be repetitive. What kinds of
additional projects are being looked into within the next year?

2) What kinds of projects utilizing Xen are being looked at? What kind of
research would be useful?

3) How viable is this idea? I will need to have an idea for a thesis
pretty much pinned down at the beginning of the fall semester next year
(around September). Should I continue to pursue Xen as a topic for
research and thesis work?

4) What is the best way to continue to stay in touch with the community?
Is this the best list? If this e-mail would be better served, or would be
more appropriate on another list, where should I send it?


Thank you very much for reading this e-mail, and please excuse me if I
have posted this in the wrong place. I appreciate any responses (even
"This is the worst idea I''ve ever heard" or "What are
you thinking?"), and
I look forward to further communication with any interested parties.


Thank you again!

Travis Vachon, Williams College class of 2006


>  
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi there,

It''d be really nice if we could find something mutually beneficial for
you to
work on.

How much experience in OS programming do you have currently?  Any experience 
hacking on the Linux / BSD kernels?  What sort of level should the project 
work be at - can you give any examples of other projects people have done?

Have you looked at the roadmap: 
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/roadmap.html for examples of 
things we''re looking at?

Cheers,
Mark

On Wednesday 11 May 2005 00:47, Travis Vachon wrote:
> To whom it may concern
>
> I am a third year Computer Science major at Williams College in
> Williamstown, Massachusetts looking into thesis work to complete the
> honors program for my degree.
>
> To fulfill the requirements for this program, I am required to perform
> independent research during the fall semester of next year leading into a
> Senior Thesis during our January term and the spring semester of 2006.
>
> I''m currently hoping to do research into virtual machines, first
by
> acquainting myself with virtualization techniques in general, and then by
> trying to focus in on modern projects, of which Xen seems to be ideal,
> given its open source nature and the recent attention it has gotten from a
> number of sources.
>
> Once this is done, for my thesis I would like to attempt to either extend
> the functionality of Xen, or use Xen in a way that is of interest to the
> virtualization community.
>
> I am e-mailing this list because I am hoping to get the input of the Xen
> developers on current long term projects within Xen or using Xen that
> would be appropriate for this kind of project (approximately 4 1/2 months
> of work, after research is complete, carrying an otherwise full
> course load).
>
> Essentially, I am hoping for answers to the following questions:
>
> 1) What additional functionality is being considered on the time scale
I''m
> looking at? Of course, I assume that most of the projects on the Xen 3.0
> roadmap are being incorporated into the next release of Xen this summer,
> so work on most of these projects would be repetitive. What kinds of
> additional projects are being looked into within the next year?
>
> 2) What kinds of projects utilizing Xen are being looked at? What kind of
> research would be useful?
>
> 3) How viable is this idea? I will need to have an idea for a thesis
> pretty much pinned down at the beginning of the fall semester next year
> (around September). Should I continue to pursue Xen as a topic for
> research and thesis work?
>
> 4) What is the best way to continue to stay in touch with the community?
> Is this the best list? If this e-mail would be better served, or would be
> more appropriate on another list, where should I send it?
>
>
> Thank you very much for reading this e-mail, and please excuse me if I
> have posted this in the wrong place. I appreciate any responses (even
> "This is the worst idea I''ve ever heard" or "What
are you thinking?"), and
> I look forward to further communication with any interested parties.
>
>
> Thank you again!
>
> Travis Vachon, Williams College class of 2006
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Mark Williamson wrote:
> OK, I''d assumed that you''d need some different models to
behave like a
> "typical" IPF system.  I guess as long as the common OSes support
a
> decent range of hardware (as Linux does) it''s not a problem...  Do
> they all have IA-64 drivers for the (comparatively low end) hardware
> that Bochs / QEmu emulates?
For DM support, we need to get ia64 to use IDE disk, Linux come with the
driver, that Qemu supports.  Ia64 uses IOSAPIC which is a subset of
IOAPIC that Qemu can support (ported from Bochs)
-Fred


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[ cc-ing to the list as you suggested]
>  I''ll probably get into this a little bit this summer, since
> understanding how to hack the code and actually doing it tend to be two
> different things.
Yeah :-)  There''s also the matter of getting familiar with the
codebase,
although there are people on the mailing lists who''ll answer questions.
> I checked the roadmap, but figured most of the things on the Xen 3.0
> roadmap were probably being worked on, since it said the planned release
> was in July, but if this isn''t the case, some of the cluster
> transparency and cluster management related projects look interesting,
> as do the CPU load balancing and QoS features.
Stephan is working on CPU load balancing, I believe.

I don''t know of anyone working on the cluster issues.  In particular,
you may
be able to find some interesting work in the cluster management area:
it''d be
nice to have cluster-wide load balancing, load monitoring, intelligent 
migration strategies, etc.
> Ideally, this project would be more than just adding filesystem support
> or something similar to Xen, as this would not be the best research topic.
I assume you mean the CoW filesystem?  It''s a reasonably challenging
project
to do well but it''s admittedly not so research-y.
> For the research roadmap it looked like the projects listed were already
> being looked at by other groups, but topics that look interesting
> include Multi-level secure Xen, and possibly the shared buffer cache and
> VM forks research.
I''ll be looking at some of the shared buffer cache stuff.  It might not
be the
best place for you to start, since it requires quite involved knowledge of 
Xen and Linux.  I think some folks are working on the VM forks (or at least 
planning to).

You might be able to find something interesting under the XenSE work once that 
gets going.
> I wasn''t sure if I should forward this to the whole list, but if
you
> think all of this information would useful to other folks, please feel
> free to send it along.
Done!  Maybe someone else will have some suggestions too.

I''ll think on it some more and let you know if there''s
anything else.  In the
meantime, you''ll probably find it useful to read the papers under 
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/architecture.html

Cheers,
Mark
> Thanks again, and I hope to be in touch with you soon!
>
> Travis
>
> Mark Williamson wrote:
> >Hi there,
> >
> >It''d be really nice if we could find something mutually
beneficial for you
> > to work on.
> >
> >How much experience in OS programming do you have currently?  Any
> > experience hacking on the Linux / BSD kernels?  What sort of level
should
> > the project work be at - can you give any examples of other projects
> > people have done?
> >
> >Have you looked at the roadmap:
> >http://www.cl.cam.ac.uk/Research/SRG/netos/xen/roadmap.html for
examples
> > of things we''re looking at?
> >
> >Cheers,
> >Mark
> >
> >On Wednesday 11 May 2005 00:47, Travis Vachon wrote:
> >>To whom it may concern
> >>
> >>I am a third year Computer Science major at Williams College in
> >>Williamstown, Massachusetts looking into thesis work to complete
the
> >>honors program for my degree.
> >>
> >>To fulfill the requirements for this program, I am required to
perform
> >>independent research during the fall semester of next year leading
into a
> >>Senior Thesis during our January term and the spring semester of
2006.
> >>
> >>I''m currently hoping to do research into virtual machines,
first by
> >>acquainting myself with virtualization techniques in general, and
then by
> >>trying to focus in on modern projects, of which Xen seems to be
ideal,
> >>given its open source nature and the recent attention it has gotten
from
> >> a number of sources.
> >>
> >>Once this is done, for my thesis I would like to attempt to either
extend
> >>the functionality of Xen, or use Xen in a way that is of interest
to the
> >>virtualization community.
> >>
> >>I am e-mailing this list because I am hoping to get the input of
the Xen
> >>developers on current long term projects within Xen or using Xen
that
> >>would be appropriate for this kind of project (approximately 4 1/2
months
> >>of work, after research is complete, carrying an otherwise full
> >>course load).
> >>
> >>Essentially, I am hoping for answers to the following questions:
> >>
> >>1) What additional functionality is being considered on the time
scale
> >> I''m looking at? Of course, I assume that most of the
projects on the Xen
> >> 3.0 roadmap are being incorporated into the next release of Xen
this
> >> summer, so work on most of these projects would be repetitive.
What
> >> kinds of additional projects are being looked into within the next
year?
> >>
> >>2) What kinds of projects utilizing Xen are being looked at? What
kind of
> >>research would be useful?
> >>
> >>3) How viable is this idea? I will need to have an idea for a
thesis
> >>pretty much pinned down at the beginning of the fall semester next
year
> >>(around September). Should I continue to pursue Xen as a topic for
> >>research and thesis work?
> >>
> >>4) What is the best way to continue to stay in touch with the
community?
> >>Is this the best list? If this e-mail would be better served, or
would be
> >>more appropriate on another list, where should I send it?
> >>
> >>
> >>Thank you very much for reading this e-mail, and please excuse me
if I
> >>have posted this in the wrong place. I appreciate any responses
(even
> >>"This is the worst idea I''ve ever heard" or
"What are you thinking?"),
> >> and I look forward to further communication with any interested
parties.
> >>
> >>
> >>Thank you again!
> >>
> >>Travis Vachon, Williams College class of 2006
> >>
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Xen-devel mailing list
> >>Xen-devel@lists.xensource.com
> >>http://lists.xensource.com/xen-devel
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

well, for my case:
- 9p-based devices, i.e. one simple protocol for all the devices a la 
  Plan 9
- ACPI
- virtualization that won''t require os mods (using AMD hardware; Intel
	is still very LinuxBIOS-unfriendly)

ron


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel