Re: Getting Physical address of a buffer
Re: Getting Physical address of a buffer
- Subject: Re: Getting Physical address of a buffer
- From: shailesh jain <email@hidden>
- Date: Mon, 9 Aug 2010 12:47:36 -0700
On Mon, Aug 9, 2010 at 11:58 AM, chas williams - CONTRACTOR
<email@hidden> wrote:
> On Mon, 9 Aug 2010 11:38:54 -0700
> shailesh jain <email@hidden> wrote:
>
>> @Mike - There are many instances where you will need physical
>> addresses. Let me point out couple of them.
>>
>> - Memory ballooning is a technique where in guest driver allocates
>> pages in the guest and passes down PPNs to the hypervisor. Hypervisor
>> takes this pages and gives it to another Virtual machine for its use.
>> Hypervisor does Physical address to Machine address (actual address in
>> Physical ram. w/o virtualization you would call this Physical address)
>> mapping.
>
> well you really dont need the physical addresses for these pages. you
> just need a mechanism to map the same physical range to multiple
> virtual ranges. you should probably be looking at the mach vm_* calls.
>
I am not sure I quite follow what you are talking about. This
technique is more like
pulling out one of the memory card from hardware and inserting into
another physical
box w/o any of the physical box knowing what happened. Because 1st box
thinks that
some driver is in need of memory and it is using it and 2nd box thinks
"oh, I always had this memory."
I clearly did not get what you are trying to say!
>> - Hypervisor wants to do fast IO - i.e read/write from/to guest memory
>> directly. Again you need physical address (different from Machine
>> address.)
>
> cpu's generally do not operate on physical (or machine) addresses.
> they generally go through your page mapper. so even if you have the
> physical address, you will need to map it at some point so the
> hypervisor can actually do something with the memory. although, i
> suppose one could be passing around buffers from a driver but the
> driver would handle the virtual/physical issue.
>
>> @Terry - Things are all good only when you have OS being the bottom
>> most layer (you have EFI et all, but still) . With virtualization -
>> you have Hypervisor underneath. Things are complicated then.
>>
>>
>>
>> Shailesh Jain
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Aug 7, 2010 at 2:42 PM, James C
>> <email@hidden> wrote:
>> > Hi Terry and Shailesh,
>> >
>> > Re (4) below, hypothetically, could that include de-powering only
>> > some parts of physical memory, when they're not needed?
>> >
>> > Shailesh, you know that the physical memory isn't contiguous. What
>> > would you think of being given the physical address of the first
>> > 0-byte segment? Why would that not meet your needs?
>> >
>> > Regards,
>> > James.
>> >
>> >> Message: 4
>> >> Date: Fri, 6 Aug 2010 20:43:42 -0700
>> >> From: Terry Lambert <email@hidden>
>> >> Subject: Re: Getting Physical address of a buffer
>> >> To: shailesh jain <email@hidden>
>> >> Cc: email@hidden
>> >> Message-ID: <email@hidden>
>> >> Content-Type: text/plain; charset=us-ascii
>> >>
>> >> This question gets asked every once in a while: "why do I have to
>> >> use OS routines to talk to hardware?".
>> >>
>> >> The basic answer is that there's virtual memory, there's wired
>> >> memory, and then there's physical memory, and all three aren't the
>> >> same thing.
>> >>
>> >> There are several reasons that an OS that runs its kernel in a
>> >> virtual address space doesn't want to give you physical address
>> >> information directly; let's briefly hit the top four on my
>> >> personal top ten list:
>> >>
>> > <snip>
>> >> (4) The OS likes to be kept informed of information for its own
>> >> reasons so it can play tricks behind your back
>> >>
>> >> The tricks themselves don't matter, what matters is that you
>> >> enable performance and power management winds by following the
>> >> rules; if you don't follow the rules, and try to avoid the OS
>> >> interfaces, you also avoid the OS signaling mechanisms that are
>> >> used to implement these optimization. Unfortunately for you, this
>> >> is like declaring a variable that is modified out of scope, and
>> >> not marking it volatile: failure to notify the OS of the nature of
>> >> your access means the OS gets to do any optimization it wants.
>> >> For a volatile variable, that may mean not exiting the work loop
>> >> when the signal handler fires. For a device driver, it generally
>> >> means a panic in the driver.
>> >>
>> >> -- Terry
>> > _______________________________________________
>> > Do not post admin requests to the list. They will be ignored.
>> > Darwin-kernel mailing list (email@hidden)
>> > Help/Unsubscribe/Update your Subscription:
>> >
>> > This email sent to email@hidden
>> >
>>
>>
>>
>
>
--
Shailesh Jain
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden