About IO

About IO

[Liu, Huahang]

[-- Attachment #1.1: Type: text/plain, Size: 150 bytes --]

 

What is the MMIO address space of Xen HVM? 

What happen when I read from or write to these IO ports? 

 

Thanks, 

         Huahang


[-- Attachment #1.2: Type: text/html, Size: 2482 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: About IO

[Li, Xin B]

>What is the MMIO address space of Xen HVM? 

>From 4G-256M to 4G, you can take a look at the definition of
HVM_BELOW_4G_MMIO_LENGTH.

>What happen when I read from or write to these IO ports? 

Depends on the devices located there, if no device, Read returns ~0,
while writes are ignored.
-Xin

RE: About IO

[Liu, Huahang]

Basically, I am interested about the following address: 
0xFFFE0000 to 0xFFFF0000

I want to know is there already any handlers for this area. 

If yes, where is the handler and what does it do? 

If no, how to add one? 

Thanks,
         Huahang

-----Original Message-----
From: Li, Xin B 
Sent: Friday, March 30, 2007 11:37 AM
To: Liu, Huahang; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] About IO

>What is the MMIO address space of Xen HVM? 

>From 4G-256M to 4G, you can take a look at the definition of
HVM_BELOW_4G_MMIO_LENGTH.

>What happen when I read from or write to these IO ports? 

Depends on the devices located there, if no device, Read returns ~0,
while writes are ignored.
-Xin

Re: About IO

[Keir Fraser]

On 3/4/07 02:57, "Liu, Huahang" <huahang.liu@intel.com> wrote:

> Basically, I am interested about the following address:
> 0xFFFE0000 to 0xFFFF0000
> 
> I want to know is there already any handlers for this area.
> 
> If yes, where is the handler and what does it do?

There's no MMIO that close to the 4GB boundary. The last handler is at
0xfee00000, for the virtual IO-APIC.

> If no, how to add one?

See numerous examples (e.g., vlapic.c , vioapic.c) for how to add a handler
inside Xen.

 -- Keir

RE: About IO

[Guy Zana]

[-- Attachment #1.1: Type: text/plain, Size: 1156 bytes --]

When a guest access a pseudo physical memory address, the hypervisor tries to translate it to the equivalent machine address (real memory). If the address does not exist in the guets's P2M (physical to machine) translation then it is considered to be mmio, in this case, a ioctl_t struct representing that access is being built and sent to the device model of the HVM guest in domain0, there it is handled by the emulated hardware.
 
Non-prefetchable MMIO (buffered) regions are being mapped to the guest's memory layout and they actually a part of it.
Since it is not prefetchable, a buffered mmio region is also mapped to the device model and being accessed "randomly", preformance is better this way.
 
Thanks,
Guy.


________________________________

	From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Liu, Huahang
	Sent: Friday, March 30, 2007 6:28 AM
	To: xen-devel@lists.xensource.com
	Subject: [Xen-devel] About IO
	
	

	 

	What is the MMIO address space of Xen HVM? 

	What happen when I read from or write to these IO ports? 

	 

	Thanks, 

	         Huahang


[-- Attachment #1.2: Type: text/html, Size: 4868 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

question about memory auto-translate and paravirtual and no pseudophysical overlay

[tgh]

hi
 I try to understand the code of xen memory
 there are gmfn, gpfn and pfn  in the xen
and in the /xen/include/xen/mm.h  there are some explanation about them 
as follows:

 * 1. gpfn/gpaddr: A guest-specific pseudo-physical frame number or address.
 * 2. gmfn/gmaddr: A machine address from the p.o.v. of a particular guest.
 * 3. mfn/maddr:   A real machine frame number or address.
 * 4. pfn/paddr:   Used in 'polymorphic' functions that work across all
 *                 address spaces, depending on context. See the pagetable
 *                 conversion macros in asm-x86/page.h for examples.
 *                 Also 'paddr_t' is big enough to store any physical 
address.
 *

I seems to understand the meaning about them,but I am confused about  
the different memory-management modes as follows

 * This scheme provides consistent function and variable names even when
 * different guests are running in different memory-management modes.
 * 1. A guest running in auto-translated mode (e.g., 
shadow_mode_translate())
 *    will have gpfn == gmfn and gmfn != mfn.
 * 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn.
 * 3. A paravirtualised guest with no pseudophysical overlay will have
 *    gpfn == gpmfn == mfn.
 *

what is the meaning about auto-translated mode,is it not the same with 
paravirtualised one ?
does the auto-translated mode work for hvm and shadow mode? how does it 
work?
and what is the mechanism about paravirtualised guest with no 
pseudophysical overlay?

I am confused about it

could you help me
Thanks in advance

question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay

[tgh]

hi
I try to understand the code of xen memory ,and I am confused  about  
the  memory-management modes,could someone help me
 
there are gmfn, gpfn and pfn  in the xen ,and in the 
/xen/include/xen/mm.h  there are some explanation about them as follows:

* 1. gpfn/gpaddr: A guest-specific pseudo-physical frame number or address.
* 2. gmfn/gmaddr: A machine address from the p.o.v. of a particular guest.
* 3. mfn/maddr:   A real machine frame number or address.
* 4. pfn/paddr:   Used in 'polymorphic' functions that work across all
*                 address spaces, depending on context. See the pagetable
*                 conversion macros in asm-x86/page.h for examples.
*                 Also 'paddr_t' is big enough to store any physical 
address.
*

I seems to understand the meaning about them,but I am confused about  
the different memory-management modes as follows

* This scheme provides consistent function and variable names even when
* different guests are running in different memory-management modes.
* 1. A guest running in auto-translated mode (e.g., 
shadow_mode_translate())
*    will have gpfn == gmfn and gmfn != mfn.
* 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn.
* 3. A paravirtualised guest with no pseudophysical overlay will have
*    gpfn == gpmfn == mfn.
*

what is the meaning about auto-translated mode,is it not the same with 
paravirtualised one ?
does the auto-translated mode work for hvm and shadow mode? how does it 
work?
and what is the mechanism about paravirtualised guest with no 
pseudophysical overlay?

I am confused about it

could you help me
Thanks in advance

Re: question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay

[Mark Williamson]

> * This scheme provides consistent function and variable names even when
> * different guests are running in different memory-management modes.
> * 1. A guest running in auto-translated mode (e.g., 
> shadow_mode_translate())
> *    will have gpfn == gmfn and gmfn != mfn.
> * 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn.
> * 3. A paravirtualised guest with no pseudophysical overlay will have
> *    gpfn == gpmfn == mfn.
> *
> 
> what is the meaning about auto-translated mode,is it not the same with 
> paravirtualised one ?

An auto-translated paravirtualised guest could be Xen-aware in its
memory management code but Xen would be hiding the underlying memory
layout from it.  This is not the normal case - I'm not actually sure
it's supported these days, although it has worked in the past.

Essentially, though and autotranslated guest doesn't need to have any
awareness of the machine memory layout, it can just pretend its got all
the memory.

> does the auto-translated mode work for hvm and shadow mode? how does it 
> work?

HVM also has a version of autotranslate mode (does it have another name
for HVM?  I'm not sure...) - HVM guests always expect that they own
*all* the memory in the machine, so they need to have the real memory
layout concealed from them.  This is done by shadowing the guest's
pagetables so that a gmfn->mfn translation can be applied to them before
inserting them into the real pagetables.

> and what is the mechanism about paravirtualised guest with no 
> pseudophysical overlay?

This would be a guest that didn't use the abstraction of pseudophysical
addresses at all; it would just use virtual and (real) machine
addresses.  I'm not sure if there are any guests that operate in this
way...  Certainly the major heavyweight OSes all use this technique when
paravirtualised.

HTH,
Cheers,
Mark

Re: question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay

[tgh]

Thank you for your reply

Mark Williamson 写道:
> This would be a guest that didn't use the abstraction of pseudophysical
> addresses at all; it would just use virtual and (real) machine
> addresses.  I'm not sure if there are any guests that operate in this
> way...  Certainly the major heavyweight OSes all use this technique when
> paravirtualised.
>
>   
what is the major heavyweight OSes? and how does it paravirtualise?
if there is no pseudophysical addresses,a physical host computer could
only paravirtualise one VM,is it right?



Thank you in advance

>
>   

Re: question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay

[Mark Williamson]

> Mark Williamson 写道:
> > This would be a guest that didn't use the abstraction of pseudophysical
> > addresses at all; it would just use virtual and (real) machine
> > addresses.  I'm not sure if there are any guests that operate in this
> > way...  Certainly the major heavyweight OSes all use this technique when
> > paravirtualised.
>
> what is the major heavyweight OSes?

I was referring to the full general purpose OSes that have been ported to Xen, 
i.e.: Linux, NetBSD, Solaris, etc.

> and how does it paravirtualise? 

These all use pseudophysical addresses to maintain the abstraction of a 
vaguely "normal" memory model for their core memory management code to work 
with, then the Xen architecture code in each OS translates these into real 
machine addresses so that everything works properly.

> if there is no pseudophysical addresses,a physical host computer could
> only paravirtualise one VM,is it right?

No, AFAIK pseudophysical addresses are mostly there for the convenience of the 
guest.  Xen has some support for them so that guests can use them more 
efficiently but that's not strictly necessary.  In principle, they could be 
eliminated from Xen entirely (would require modifying the PV guests to manage 
the pseudophys abstraction themselves).

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay

[tgh]

hi
Thank you for your reply


Mark Williamson 写道:
>> if there is no pseudophysical addresses,a physical host computer could
>> only paravirtualise one VM,is it right?
>>     
>
> No, AFAIK pseudophysical addresses are mostly there for the convenience of the 
> guest.  Xen has some support for them so that guests can use them more 
> efficiently but that's not strictly necessary.  In principle, they could be 
> eliminated from Xen entirely (would require modifying the PV guests to manage 
> the pseudophys abstraction themselves).
>   
Is there this kind paravirtual os for xen at present?
or in future,will this kind paravirtual os come out?
and what is the advantages for this kind of os?

Thanks in advance

Re: question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay

[Mark Williamson]

Nb. I'm focussing on x86 (and x86_32 where appropriate) here and have been in 
the rest of the thread (unless otherwise specified)...  other architectures 
deal with pseudophysical addressses differently.

> Mark Williamson 写道:
> >> if there is no pseudophysical addresses,a physical host computer could
> >> only paravirtualise one VM,is it right?
> >
> > No, AFAIK pseudophysical addresses are mostly there for the convenience
> > of the guest.  Xen has some support for them so that guests can use them
> > more efficiently but that's not strictly necessary.  In principle, they
> > could be eliminated from Xen entirely (would require modifying the PV
> > guests to manage the pseudophys abstraction themselves).
>
> Is there this kind paravirtual os for xen at present?
> or in future,will this kind paravirtual os come out?
> and what is the advantages for this kind of os?

There's two aspects to this answer, I guess:

1) Will guests which maintain their own pseudophysical abstraction rather than 
using Xen's be written?  /  Will Xen's pseudophysical support be removed?

This isn't likely for the timebeing; Xen needs to incorporate the 
pseudophysical support it has for backwards-compatibility purposes and given 
that there's no reason for guests not to use it.

2) Will guests that don't use a pseudophysical abstraction at all be written?

I don't know if anyone has written / ported an OS that does this...  I 
wouldn't expect to see any general purpose OSes using this for a while - they 
typically seem to need the pseudophysical abstraction to keep their generic 
memory management code happy.

More minimal, special purposes OSes (especially if targetted to Xen) might be 
able to do away with pseudophysical addresses entirely and just use virtual 
and machine addresses.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay

[tgh]

Thank you for your reply

Thank you


Mark Williamson 写道:
> Nb. I'm focussing on x86 (and x86_32 where appropriate) here and have been in 
> the rest of the thread (unless otherwise specified)...  other architectures 
> deal with pseudophysical addressses differently.
>
>   
>> Mark Williamson 写道:
>>     
>>>> if there is no pseudophysical addresses,a physical host computer could
>>>> only paravirtualise one VM,is it right?
>>>>         
>>> No, AFAIK pseudophysical addresses are mostly there for the convenience
>>> of the guest.  Xen has some support for them so that guests can use them
>>> more efficiently but that's not strictly necessary.  In principle, they
>>> could be eliminated from Xen entirely (would require modifying the PV
>>> guests to manage the pseudophys abstraction themselves).
>>>       
>> Is there this kind paravirtual os for xen at present?
>> or in future,will this kind paravirtual os come out?
>> and what is the advantages for this kind of os?
>>     
>
> There's two aspects to this answer, I guess:
>
> 1) Will guests which maintain their own pseudophysical abstraction rather than 
> using Xen's be written?  /  Will Xen's pseudophysical support be removed?
>
> This isn't likely for the timebeing; Xen needs to incorporate the 
> pseudophysical support it has for backwards-compatibility purposes and given 
> that there's no reason for guests not to use it.
>
> 2) Will guests that don't use a pseudophysical abstraction at all be written?
>
> I don't know if anyone has written / ported an OS that does this...  I 
> wouldn't expect to see any general purpose OSes using this for a while - they 
> typically seem to need the pseudophysical abstraction to keep their generic 
> memory management code happy.
>
> More minimal, special purposes OSes (especially if targetted to Xen) might be 
> able to do away with pseudophysical addresses entirely and just use virtual 
> and machine addresses.
>
> Cheers,
> Mark
>
>