[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings
On 2014/8/29 17:18, Jan Beulich wrote: On 29.08.14 at 05:02, <tiejun.chen@xxxxxxxxx> wrote:I tried to figure out solution as you suggestion but I'd like show my draft design before post anything to review since please give some suggestions here: 1. In the xen/include/xen/iommu.h file, struct iommu_ops { ... int (*get_device_reserved_memory)(struct list_head *dev_reserved_memory); 2. In the xen/drivers/passthrough/vtd/iommu.c file, extern int get_device_acpi_reserved_memory(struct list_head *dev_reserved_memory); const struct iommu_ops intel_iommu_ops = { ... .get_device_reserved_memory = get_device_acpi_reserved_memory, 3. In the xen/drivers/passthrough/vtd/dmar.c file, struct list_head devices_reserved_memory = LIST_HEAD_INIT ( devices_reserved_memory ); int get_device_acpi_reserved_memory(struct list_head *dev_reserved_memory) { static unsigned int device_reserved_memory_entries = 0; static unsigned int check_done = 0; struct acpi_rmrr_unit *rmrru; struct device_acpi_reserved_memory *darm = NULL; dev_reserved_memory = &devices_reserved_memory; if ( check_done ) return device_reserved_memory_entries; else { list_for_each_entry(rmrru, &acpi_rmrr_units, list) { darm = xzalloc(struct device_acpi_reserved_memory); if ( !darm ) return -ENOMEM; darm->base_address = rmrru->base_address; darm->end_address = rmrru->end_address; list_add(&darm->list, &devices_reserved_memory); device_reserved_memory_entries++; } } check_done = 1; return device_reserved_memory_entries; } 4. In the xen/include/asm-x86/acpi.h file, +struct device_acpi_reserved_memory { + struct list_head list; + u64 base_address; + u64 end_address; +}; Here a couple of questions: 1. Here I introduce this struct device_acpi_reserved_memory to avoid exposing that existing structure and list acpi_rmrr_units struct acpi_rmrr_unit { struct dmar_scope scope; struct list_head list; u64 base_address; u64 end_address; u16 segment; u8 allow_all:1; }; Because: 1> Actually we just need two fields, base_address and end_address. 2> If reuse that structure, we still have to change some head files to make sure we can use this in other files like I did in original patch #1 you don't like. So what is your idea? 2. Based on your isolation policy, I don't expose acpi_rmrr_units directly. Instead, I will copy this to another list, devices_reserved_memory as I show above. Is this reasonable and expected?This still allocates another instance of structures to create a second linked list. Did you consider get_device_reserved_memory() to take Do you mean we still use this existing type combo, acpi_rmrr_units and acpi_rmrr_units? a callback function instead? But we should do something like this, 1. .get_device_reserved_memory = get_drm_all, 2. static int get_drm_all(struct list_head *dev_reserved_memory) { return (get_drm_callback(dev_reserved_memory)); } 3. get_drm_callback = get_device_acpi_reserved_memory;4. static int get_device_acpi_reserved_memory(struct list_head *dev_reserved_memory) { ... dev_reserved_memory = &acpi_rmrr_units; ... } Then while calling the hypercall, struct list_head *dev_reserved_memory = NULL; nr_entries = ops->get_device_reserved_memory(dev_reserved_memory); if (!nr_entries) list_for_each_entry( darm, dev_reserved_memory, list ) { xxx.start_pfn = ...; xxx.nr_pages = ...; if ( copy_to_guest_offset(buffer, i, &xxx, 1) ) ... } Thanks Tiejun _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |