From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org,
xen-devel@lists.xen.org
Subject: Re: [v7][RFC][PATCH 05/13] hvmloader/mmio: reconcile guest mmio with reserved device memory
Date: Mon, 27 Oct 2014 15:12:47 +0800 [thread overview]
Message-ID: <544DF06F.5000106@intel.com> (raw)
In-Reply-To: <544A81610200007800041FFE@mail.emea.novell.com>
On 2014/10/24 22:42, Jan Beulich wrote:
>>>> On 24.10.14 at 09:34, <tiejun.chen@intel.com> wrote:
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -37,6 +37,44 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>> enum virtual_vga virtual_vga = VGA_none;
>> unsigned long igd_opregion_pgbase = 0;
>>
>> +unsigned int need_skip_rmrr = 0;
>
> Static (and without initializer)?
static unsigned int need_skip_rmrr;
>
>> +
>> +/*
>> + * Check whether there exists mmio hole in the specified memory range.
>> + * Returns 1 if exists, else returns 0.
>> + */
>> +static int check_mmio_hole_confliction(uint64_t start, uint64_t memsize,
>
> I don't think the word "confliction" exists. "conflict" please.
s/check_mmio_hole_confliction/check_mmio_hole_conflict/g
>
>> + uint64_t mmio_start, uint64_t mmio_size)
>> +{
>> + if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
>> + return 0;
>> + else
>> + return 1;
>
> Make this a simple single return statement?
static int check_mmio_hole_conflict(uint64_t start, uint64_t memsize,
uint64_t mmio_start, uint64_t
mmio_size)
{
if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
return 0;
return 1;
}
>
>> +}
>> +
>> +static int check_reserved_device_memory_map(uint64_t mmio_base,
>> + uint64_t mmio_max)
>> +{
>> + uint32_t i = 0;
>
> Pointless initializer.
>
>> + uint64_t rdm_start, rdm_end;
>> + int nr_entries = -1;
>
> And again.
>
>> +
>> + nr_entries = hvm_get_reserved_device_memory_map();
>
> It's completely unclear why this can't be the variable's initializer.
uint32_t i;
uint64_t rdm_start, rdm_end;
int nr_rdm_entries = hvm_get_reserved_device_memory_map();
>
>> +
>> + for ( i = 0; i < nr_entries; i++ )
>> + {
>> + rdm_start = rdm_map[i].start_pfn << PAGE_SHIFT;
>> + rdm_end = rdm_start + (rdm_map[i].nr_pages << PAGE_SHIFT);
>
> I'm pretty certain I pointed out before that you can't simply shift
> these fields - you risk losing significant bits.
I tried to go back looking into something but just found you were saying
I shouldn't use PAGE_SHIFT and PAGE_SIZE at the same time. If I'm still
missing could you show me what you expect?
>
>> + if ( check_mmio_hole_confliction(rdm_start, (rdm_end - rdm_start),
>
> Pointless parentheses.
if ( check_mmio_hole_conflict(rdm_start, rdm_end - rdm_start,
>
>> + mmio_base, mmio_max - mmio_base) )
>> + {
>> + need_skip_rmrr++;
>> + }
>> + }
>> +
>> + return nr_entries;
>> +}
>> +
>> void pci_setup(void)
>> {
>> uint8_t is_64bar, using_64bar, bar64_relocate = 0;
>> @@ -58,7 +96,9 @@ void pci_setup(void)
>> uint32_t bar_reg;
>> uint64_t bar_sz;
>> } *bars = (struct bars *)scratch_start;
>> - unsigned int i, nr_bars = 0;
>> + unsigned int i, j, nr_bars = 0;
>> + int nr_entries = 0;
>
> And another pointless initializer. Plus as a count of something this
int nr_rdm_entries;
> surely wants to be "unsigned int". Also I guess the variable name
nr_rdm_entries should be literally unsigned int but this value always be
set from hvm_get_reserved_device_memory_map(),
nr_rdm_entries = hvm_get_reserved_device_memory_map()
I hope that return value can be negative value in some failed case
> is too generic - nr_rdm_entries perhaps?
Okay, s/nr_entries/nr_rdm_entries/g
>
>> @@ -363,11 +411,29 @@ void pci_setup(void)
>> bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
>> }
>>
>> + reallocate_mmio:
>> base = (resource->base + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
>> bar_data |= (uint32_t)base;
>> bar_data_upper = (uint32_t)(base >> 32);
>> base += bar_sz;
>>
>> + if ( need_skip_rmrr )
>> + {
>> + for ( j = 0; j < nr_entries; j++ )
>> + {
>> + rdm_start = rdm_map[j].start_pfn << PAGE_SHIFT;
>> + rdm_end = rdm_start + (rdm_map[j].nr_pages << PAGE_SHIFT);
>> + if ( check_mmio_hole_confliction(rdm_start,
>> + (rdm_end - rdm_start),
>> + base, bar_sz) )
>
> "base" was already updated by this point.
Looks I should insert these code fragments between
bar_data_upper = (uint32_t)(base >> 32);
and
base += bar_sz;
So (See below)
>
>> + {
>> + resource->base = rdm_end;
>> + need_skip_rmrr--;
>> + goto reallocate_mmio;
>
> If you ever get here, the earlier determination of whether the MMIO
> hole is large enough may get invalidated. I.e. I'm afraid this approach
> is still to simplistic. Also to way you do the retry, the resulting bar_data
Here move 'reallocate_mmio' downward one line, and
s/resource->base = rdm_end;/base = (rdm_end + bar_sz - 1) &
~(uint64_t)(bar_sz - 1);
Then,
...
base = (resource->base + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
reallocate_mmio:
bar_data |= (uint32_t)base;
bar_data_upper = (uint32_t)(base >> 32);
if ( need_skip_rmrr )
{
for ( j = 0; j < nr_rdm_entries; j++ )
{
rdm_start = rdm_map[j].start_pfn << PAGE_SHIFT;
rdm_end = rdm_start + (rdm_map[j].nr_pages << PAGE_SHIFT);
if ( check_mmio_hole_conflict(rdm_start, rdm_end -
rdm_start,
base, bar_sz) )
{
base = (rdm_end + bar_sz - 1) & ~(uint64_t)(bar_sz
- 1);
need_skip_rmrr--;
goto reallocate_mmio;
}
}
}
base += bar_sz;
Additionally, actually there are some original codes just following my
codes:
if ( need_skip_rmrr )
{
...
}
base += bar_sz;
if ( (base < resource->base) || (base > resource->max) )
{
printf("pci dev %02x:%x bar %02x size "PRIllx": no space for "
"resource!\n", devfn>>3, devfn&7, bar_reg,
PRIllx_arg(bar_sz));
continue;
}
This can guarantee we don't overwhelm the previous mmio range.
> and bar_data_upper will likely end up being garbage.
>
> Did you actually _test_ this code?
Actually in my real case those RMRR ranges are always below MMIO.
Thanks
Tiejun
next prev parent reply other threads:[~2014-10-27 7:12 UTC|newest]
Thread overview: 180+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 7:34 [v7][RFC][PATCH 01/13] xen: RMRR fix Tiejun Chen
2014-10-24 7:34 ` [v7][RFC][PATCH 01/13] introduce XENMEM_reserved_device_memory_map Tiejun Chen
2014-10-24 14:11 ` Jan Beulich
2014-10-27 2:11 ` Chen, Tiejun
2014-10-27 2:18 ` Chen, Tiejun
2014-10-27 9:42 ` Jan Beulich
2014-10-28 2:22 ` Chen, Tiejun
2014-10-27 13:35 ` Julien Grall
2014-10-28 2:35 ` Chen, Tiejun
2014-10-28 10:36 ` Jan Beulich
2014-10-29 0:40 ` Chen, Tiejun
2014-10-29 8:53 ` Jan Beulich
2014-10-30 2:53 ` Chen, Tiejun
2014-10-30 9:10 ` Jan Beulich
2014-10-31 1:03 ` Chen, Tiejun
2014-10-24 7:34 ` [v7][RFC][PATCH 02/13] tools/libxc: introduce hypercall for xc_reserved_device_memory_map Tiejun Chen
2014-10-24 7:34 ` [v7][RFC][PATCH 03/13] tools/libxc: check if modules space is overlapping with reserved device memory Tiejun Chen
2014-10-24 7:34 ` [v7][RFC][PATCH 04/13] hvmloader/util: get reserved device memory maps Tiejun Chen
2014-10-24 14:22 ` Jan Beulich
2014-10-27 3:12 ` Chen, Tiejun
2014-10-27 9:45 ` Jan Beulich
2014-10-28 5:21 ` Chen, Tiejun
2014-10-28 9:48 ` Jan Beulich
2014-10-29 6:54 ` Chen, Tiejun
2014-10-29 9:05 ` Jan Beulich
2014-10-30 5:55 ` Chen, Tiejun
2014-10-30 9:13 ` Jan Beulich
2014-10-31 2:20 ` Chen, Tiejun
2014-10-31 8:14 ` Jan Beulich
2014-11-03 2:22 ` Chen, Tiejun
2014-11-03 8:53 ` Jan Beulich
2014-11-03 9:32 ` Chen, Tiejun
2014-11-03 9:45 ` Jan Beulich
2014-11-03 9:55 ` Chen, Tiejun
2014-11-03 10:02 ` Jan Beulich
2014-11-21 6:26 ` Chen, Tiejun
2014-11-21 7:43 ` Tian, Kevin
2014-11-21 7:54 ` Jan Beulich
2014-11-21 8:01 ` Tian, Kevin
2014-11-21 8:54 ` Chen, Tiejun
2014-11-21 9:33 ` Jan Beulich
2014-10-24 14:27 ` Jan Beulich
2014-10-27 5:07 ` Chen, Tiejun
2014-10-24 7:34 ` [v7][RFC][PATCH 05/13] hvmloader/mmio: reconcile guest mmio with reserved device memory Tiejun Chen
2014-10-24 14:42 ` Jan Beulich
2014-10-27 7:12 ` Chen, Tiejun [this message]
2014-10-27 9:56 ` Jan Beulich
2014-10-28 7:11 ` Chen, Tiejun
2014-10-28 9:56 ` Jan Beulich
2014-10-29 7:03 ` Chen, Tiejun
2014-10-29 9:08 ` Jan Beulich
2014-10-30 3:18 ` Chen, Tiejun
2014-10-24 7:34 ` [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps Tiejun Chen
2014-10-24 14:56 ` Jan Beulich
2014-10-27 8:09 ` Chen, Tiejun
2014-10-27 10:17 ` Jan Beulich
2014-10-28 7:47 ` Chen, Tiejun
2014-10-28 10:06 ` Jan Beulich
2014-10-29 7:43 ` Chen, Tiejun
2014-10-29 9:15 ` Jan Beulich
2014-10-30 3:11 ` Chen, Tiejun
2014-10-30 9:20 ` Jan Beulich
2014-10-31 5:41 ` Chen, Tiejun
2014-10-31 6:21 ` Tian, Kevin
2014-10-31 7:02 ` Chen, Tiejun
2014-10-31 8:20 ` Jan Beulich
2014-11-03 5:49 ` Chen, Tiejun
2014-11-03 8:56 ` Jan Beulich
2014-11-03 9:40 ` Chen, Tiejun
2014-11-03 9:51 ` Jan Beulich
2014-11-03 11:32 ` Chen, Tiejun
2014-11-03 11:43 ` Jan Beulich
2014-11-03 11:58 ` Chen, Tiejun
2014-11-03 12:34 ` Jan Beulich
2014-11-04 5:05 ` Chen, Tiejun
2014-11-04 7:54 ` Jan Beulich
2014-11-05 2:59 ` Chen, Tiejun
2014-11-05 17:00 ` Jan Beulich
2014-11-06 9:28 ` Chen, Tiejun
2014-11-06 10:06 ` Jan Beulich
2014-11-07 10:27 ` Chen, Tiejun
2014-11-07 11:08 ` Jan Beulich
2014-11-11 6:32 ` Chen, Tiejun
2014-11-11 7:49 ` Chen, Tiejun
2014-11-11 9:03 ` Jan Beulich
2014-11-11 9:06 ` Jan Beulich
2014-11-11 9:42 ` Chen, Tiejun
2014-11-11 10:07 ` Jan Beulich
2014-11-12 1:36 ` Chen, Tiejun
2014-11-12 8:37 ` Jan Beulich
2014-11-12 8:45 ` Chen, Tiejun
2014-11-12 9:02 ` Jan Beulich
2014-11-12 9:13 ` Chen, Tiejun
2014-11-12 9:56 ` Jan Beulich
2014-11-12 10:18 ` Chen, Tiejun
2014-11-19 8:17 ` Tian, Kevin
2014-11-20 7:45 ` Tian, Kevin
2014-11-20 8:04 ` Jan Beulich
2014-11-20 8:51 ` Tian, Kevin
2014-11-20 14:40 ` Tian, Kevin
2014-11-20 14:46 ` Jan Beulich
2014-11-20 20:11 ` Konrad Rzeszutek Wilk
2014-11-21 0:32 ` Tian, Kevin
2014-11-12 3:05 ` Chen, Tiejun
2014-11-12 8:55 ` Jan Beulich
2014-11-12 10:18 ` Chen, Tiejun
2014-11-12 10:24 ` Jan Beulich
2014-11-12 10:32 ` Chen, Tiejun
2014-11-13 3:09 ` Chen, Tiejun
2014-11-14 2:21 ` Chen, Tiejun
2014-11-14 8:21 ` Jan Beulich
2014-11-17 7:31 ` Chen, Tiejun
2014-11-17 7:57 ` Chen, Tiejun
2014-11-17 10:05 ` Jan Beulich
2014-11-17 11:08 ` Chen, Tiejun
2014-11-17 11:17 ` Jan Beulich
2014-11-17 11:32 ` Chen, Tiejun
2014-11-17 11:51 ` Jan Beulich
2014-11-18 3:08 ` Chen, Tiejun
2014-11-18 8:01 ` Jan Beulich
2014-11-18 8:16 ` Chen, Tiejun
2014-11-18 9:33 ` Jan Beulich
2014-11-19 1:26 ` Chen, Tiejun
2014-11-20 7:31 ` Jan Beulich
2014-11-20 8:12 ` Chen, Tiejun
2014-11-20 8:59 ` Jan Beulich
2014-11-20 10:28 ` Chen, Tiejun
2014-11-11 8:59 ` Jan Beulich
2014-11-11 9:35 ` Chen, Tiejun
2014-11-11 9:42 ` Jan Beulich
2014-11-11 9:51 ` Chen, Tiejun
2014-10-24 7:34 ` [v7][RFC][PATCH 07/13] xen/x86/p2m: introduce p2m_check_reserved_device_memory Tiejun Chen
2014-10-24 15:02 ` Jan Beulich
2014-10-27 8:50 ` Chen, Tiejun
2014-10-24 7:34 ` [v7][RFC][PATCH 08/13] xen/x86/p2m: set p2m_access_n for reserved device memory mapping Tiejun Chen
2014-10-24 15:11 ` Jan Beulich
2014-10-27 9:05 ` Chen, Tiejun
2014-10-27 10:33 ` Jan Beulich
2014-10-28 8:26 ` Chen, Tiejun
2014-10-28 10:12 ` Jan Beulich
2014-10-29 8:20 ` Chen, Tiejun
2014-10-29 9:20 ` Jan Beulich
2014-10-30 7:39 ` Chen, Tiejun
2014-10-30 9:24 ` Jan Beulich
2014-10-31 2:50 ` Chen, Tiejun
2014-10-31 8:25 ` Jan Beulich
2014-11-03 6:20 ` Chen, Tiejun
2014-11-03 9:00 ` Jan Beulich
2014-11-03 9:51 ` Chen, Tiejun
2014-11-03 10:03 ` Jan Beulich
2014-11-03 11:48 ` Chen, Tiejun
2014-11-03 11:53 ` Jan Beulich
2014-11-04 1:35 ` Chen, Tiejun
2014-11-04 8:02 ` Jan Beulich
2014-11-04 10:41 ` Chen, Tiejun
2014-11-04 11:41 ` Jan Beulich
2014-11-04 11:51 ` Chen, Tiejun
2014-10-24 7:34 ` [v7][RFC][PATCH 09/13] xen/x86/ept: handle reserved device memory in ept_handle_violation Tiejun Chen
2014-10-24 7:34 ` [v7][RFC][PATCH 10/13] xen/x86/p2m: introduce set_identity_p2m_entry Tiejun Chen
2014-10-24 7:34 ` [v7][RFC][PATCH 11/13] xen:vtd: create RMRR mapping Tiejun Chen
2014-10-24 7:34 ` [v7][RFC][PATCH 12/13] xen/vtd: re-enable USB device assignment Tiejun Chen
2014-10-24 7:34 ` [v7][RFC][PATCH 13/13] xen/vtd: group assigned device with RMRR Tiejun Chen
2014-10-24 10:52 ` [v7][RFC][PATCH 01/13] xen: RMRR fix Jan Beulich
2014-10-27 2:00 ` Chen, Tiejun
2014-10-27 9:41 ` Jan Beulich
2014-10-28 8:36 ` Chen, Tiejun
2014-10-28 9:34 ` Jan Beulich
2014-10-28 9:39 ` Razvan Cojocaru
2014-10-29 0:51 ` Chen, Tiejun
2014-10-29 0:48 ` Chen, Tiejun
2014-10-29 2:51 ` Chen, Tiejun
2014-10-29 8:45 ` Jan Beulich
2014-10-30 8:21 ` Chen, Tiejun
2014-10-30 9:07 ` Jan Beulich
2014-10-31 3:11 ` Chen, Tiejun
2014-10-29 8:44 ` Jan Beulich
2014-10-30 2:51 ` Chen, Tiejun
2014-10-30 22:15 ` Tim Deegan
2014-10-31 2:53 ` Chen, Tiejun
2014-10-31 9:10 ` Tim Deegan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544DF06F.5000106@intel.com \
--to=tiejun.chen@intel.com \
--cc=JBeulich@suse.com \
--cc=kevin.tian@intel.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.