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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).