Re: The way of mapping BIOS into the guest's address space

2012-02-14 Thread cody

On 02/14/2012 07:03 PM, Yang Bai wrote:

Hi all,

Since on X86, bios is always at the end of the address space, so I
have some thought about how to implement the seabios support for kvm
tool.

1. using kvm__register_mem to map the end of address space to the
guest then copy the code of seabios to this mem region. Just emulating
the bios chip.

2. leave the bios code alone and don't touch the guest's address
space. If the guest accesses the address belonging to the bios, it
will be an IO request and we can emulate the IO access to the bios
chip.

Any ideas about this?
   
Can I ask what's the purpose of mapping BIOS code to guest? Any usage? 
Shouldn't BIOS's behavior be emulated by hypervisor? Thanks.


-cody

And question:  How could I set the first instruction address after we
issue the vmlaunch instruction?

Thanks,
Yang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
   


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware

2011-11-10 Thread cody

On 11/10/2011 09:08 PM, Joerg Roedel wrote:

On Thu, Nov 10, 2011 at 08:16:16PM +0800, cody wrote:
   

On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
 

On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang   wrote:
   

Seems the unmap function don't take phys as parameter, does this mean
domain->ops->unmap will walk through the page table to find out the
actual page size?
 

The short answer is yes, and furthermore, we also consider to remove
the size param from domain->ops->unmap entirely at some point.

We had a long discussion about it, please see:

https://lkml.org/lkml/2011/10/10/234
   

Yes I've seen your discussion, I followed this thread from beginning:)

How about the IOTLB flush? As I said I think we need to consider
that IOMMU (even does not exist now) may have some limitation on
IOTLB flush, and hiding page size from IOTLB flush code may hurt
performance, or even worse, trigger undefined behaviors.
 

We can only care about IOMMUs that exist today or ones that will exist
and we already know of.
In general for the hardware I know of a page-size is not required for
implementing unmap operations. Requiring this would imply that any user
of the IOMMU-API needs to keeps track of the page-sizes used to map a
given area.
This would be a huge burden which is not really necessary because the
IOMMU driver already has this information and can return it to the user.
So if you want to change that you need a very good reason for it.

   
Yes I totally agree page-size is not required for unmap operations and 
should not be added as parameter to map/unmap operations. I am not 
saying the unmap operation, but the IOTLB flush operation. My point is 
we also may also need to add similar logic in IOTLB flush code (such as 
in Intel IOMMU dirver) to grantee that when issuing IOTLB flush command 
for large page, we will still meet the hardware limitation of flushing 
large page. Seems for Intel IOMMU the only limitation is the mask value 
(indicating number of 4k-pages) cannot be smaller than the value to 
cover large page, and seems current Intel IOMMU driver code has covered 
this case well. I am not familiar with how AMD IOMMU issues IOTLB flush 
command, it should be able to handle this large page case too. So at 
this moment, this patch should not have any issues :)


-cody

Joerg

   


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware

2011-11-10 Thread cody

On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:

On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang  wrote:
   

Seems the unmap function don't take phys as parameter, does this mean
domain->ops->unmap will walk through the page table to find out the
actual page size?
 

The short answer is yes, and furthermore, we also consider to remove
the size param from domain->ops->unmap entirely at some point.

We had a long discussion about it, please see:

https://lkml.org/lkml/2011/10/10/234
   

Yes I've seen your discussion, I followed this thread from beginning:)

How about the IOTLB flush? As I said I think we need to consider that 
IOMMU (even does not exist now) may have some limitation on IOTLB flush, 
and hiding page size from IOTLB flush code may hurt performance, or even 
worse, trigger undefined behaviors.


-cody
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html