On 2015/7/16 17:40, George Dunlap wrote:
On Thu, Jul 16, 2015 at 3:05 AM, Chen, Tiejun wrote:
Could you take a look at the original patch #06 ? Although Jan thought that
is complicated, that is really one version that I can refine in current time
slot.
When you say "original", which version
On Thu, Jul 16, 2015 at 3:05 AM, Chen, Tiejun wrote:
> Could you take a look at the original patch #06 ? Although Jan thought that
> is complicated, that is really one version that I can refine in current time
> slot.
When you say "original", which version are you talking about? You
mean the on
On 2015/7/16 0:14, George Dunlap wrote:
On Wed, Jul 15, 2015 at 2:56 PM, George Dunlap
wrote:
Would it be possible, on a collision, to have one last "stab" at
allocating the BAR somewhere else, without relocating memory (or
relocating any other BARs)? At very least then an administrator could
On Wed, Jul 15, 2015 at 2:56 PM, George Dunlap
wrote:
> Would it be possible, on a collision, to have one last "stab" at
> allocating the BAR somewhere else, without relocating memory (or
> relocating any other BARs)? At very least then an administrator could
> work around this kind of thing by s
On Wed, Jul 15, 2015 at 3:00 PM, Jan Beulich wrote:
On 15.07.15 at 15:40, wrote:
>> On Mon, Jul 13, 2015 at 2:12 PM, Jan Beulich wrote:
>>> Therefore I'll not make any further comments on the rest of the
>>> patch, but instead outline an allocation model that I think would
>>> fit our needs
>>> On 15.07.15 at 15:40, wrote:
> On Mon, Jul 13, 2015 at 2:12 PM, Jan Beulich wrote:
>> Therefore I'll not make any further comments on the rest of the
>> patch, but instead outline an allocation model that I think would
>> fit our needs: Subject to the constraints mentioned above, set up
>> a
On Wed, Jul 15, 2015 at 12:34 PM, Chen, Tiejun wrote:
>>> Maybe I can move this chunk of codes downward those actual allocation
>>> to check if RDM conflicts with the final allocation, and then just
>>> disable those associated devices by writing PCI_COMMAND without BUG()
>>> like this draft code
On Mon, Jul 13, 2015 at 2:12 PM, Jan Beulich wrote:
> Therefore I'll not make any further comments on the rest of the
> patch, but instead outline an allocation model that I think would
> fit our needs: Subject to the constraints mentioned above, set up
> a bitmap (maximum size 64k [2Gb = 2^^19 pa
Is not booting worse than what we have now -- which is, booting
successfully but (probably) having issues due to MMIO ranges
overlapping RMRRs?
Its really so rare possibility here since in the real world we didn't
see any RMRR regions >= 0xF000 (the default pci memory start.) And I
already s
On Wed, Jul 15, 2015 at 09:32:34AM +0100, Jan Beulich wrote:
> >>> On 15.07.15 at 02:55, wrote:
> >> > I agree we'd better overhaul this since we already found something
> >>> unreasonable here. But one or two weeks is really not enough to fix this
> >>> with a bitmap framework, and although a bit
On 07/15/2015 12:20 PM, Chen, Tiejun wrote:
> On 2015/7/15 19:05, George Dunlap wrote:
>> On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich wrote:
>> On 15.07.15 at 10:59, wrote:
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, wrote:
>> Furthermore, could we have t
On 2015/7/15 19:27, Jan Beulich wrote:
On 15.07.15 at 13:05, wrote:
This patch series as a whole represents a lot of work and a lot of
tangible improvements to the situation; and (unless the situation has
changed) it's almost entirely acked apart from the MMIO placement
part. If there is a sim
On 07/15/2015 12:24 PM, Jan Beulich wrote:
On 15.07.15 at 13:05, wrote:
>> On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich wrote:
>> On 15.07.15 at 10:59, wrote:
What about this?
@@ -301,6 +301,19 @@ void pci_setup(void)
pci_mem_start <<= 1;
}
Maybe I can move this chunk of codes downward those actual allocation
to check if RDM conflicts with the final allocation, and then just
disable those associated devices by writing PCI_COMMAND without BUG()
like this draft code,
And what would keep the guest from re-enabling the device?
We c
>>> On 15.07.15 at 13:05, wrote:
> This patch series as a whole represents a lot of work and a lot of
> tangible improvements to the situation; and (unless the situation has
> changed) it's almost entirely acked apart from the MMIO placement
> part. If there is a simple way that we can change hvm
>>> On 15.07.15 at 12:34, wrote:
Yet more special casing code you want to add. I said no to this
model, and unless you can address the issue _without_ adding
a lot of special casing code, the answer will remain no (subject
>>>
>>> What about this?
>>>
>>> @@ -301,6 +301,19 @@ void p
>>> On 15.07.15 at 13:05, wrote:
> On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich wrote:
> On 15.07.15 at 10:59, wrote:
>>> What about this?
>>>
>>> @@ -301,6 +301,19 @@ void pci_setup(void)
>>> pci_mem_start <<= 1;
>>> }
>>>
>>> +for ( i = 0; i < memory_map.nr_map ; i
On 2015/7/15 19:05, George Dunlap wrote:
On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich wrote:
On 15.07.15 at 10:59, wrote:
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, wrote:
Furthermore, could we have this solution as follows?
Yet more special casing code you want to add
On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich wrote:
On 15.07.15 at 10:59, wrote:
>> On 2015/7/15 16:34, Jan Beulich wrote:
>> On 15.07.15 at 06:27, wrote:
Furthermore, could we have this solution as follows?
>>>
>>> Yet more special casing code you want to add. I said no to this
>
Yet more special casing code you want to add. I said no to this
model, and unless you can address the issue _without_ adding
a lot of special casing code, the answer will remain no (subject
What about this?
@@ -301,6 +301,19 @@ void pci_setup(void)
pci_mem_start <<= 1;
}
>>> On 15.07.15 at 10:59, wrote:
> On 2015/7/15 16:34, Jan Beulich wrote:
> On 15.07.15 at 06:27, wrote:
>>> Furthermore, could we have this solution as follows?
>>
>> Yet more special casing code you want to add. I said no to this
>> model, and unless you can address the issue _without_ addi
This is very similar to our current policy to
[RESERVED_MEMORY_DYNAMIC_START, RESERVED_MEMORY_DYNAMIC_END] in patch #6
since actually this is also another rare possibility in real world. Even
I can do this as well when we handle that conflict with
[RESERVED_MEMORY_DYNAMIC_START, RESERVED_MEMORY_DY
Certainly appreciate your time.
I didn't mean its wasting time at this point. I just want to express
that its hard to implement that solution in one or two weeks to walking
into 4.6 as an exception.
Note I know this feature is still not accepted as an exception to 4.6
right now so I'm making an
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, wrote:
Furthermore, could we have this solution as follows?
Yet more special casing code you want to add. I said no to this
model, and unless you can address the issue _without_ adding
a lot of special casing code, the answer will r
>>> On 15.07.15 at 06:27, wrote:
> Furthermore, could we have this solution as follows?
Yet more special casing code you want to add. I said no to this
model, and unless you can address the issue _without_ adding
a lot of special casing code, the answer will remain no (subject
to co-maintainers o
>>> On 15.07.15 at 02:55, wrote:
>> > I agree we'd better overhaul this since we already found something
>>> unreasonable here. But one or two weeks is really not enough to fix this
>>> with a bitmap framework, and although a bitmap can make mmio allocation
>>> better, but more complicated if we j
On 2015/7/15 8:55, Chen, Tiejun wrote:
I agree we'd better overhaul this since we already found
something unreasonable here. But one or two weeks is really not
enough to fix this with a bitmap framework, and although a bitmap
can make mmio allocation better, but more complicated if we just
want t
I agree we'd better overhaul this since we already found something
unreasonable here. But one or two weeks is really not enough to fix this
with a bitmap framework, and although a bitmap can make mmio allocation
better, but more complicated if we just want to allocate PCI mmio.
So could we do thi
>>> On 14.07.15 at 12:54, wrote:
>>> I think bitmap mechanism is a good idea but honestly, its not easy to
>>> cover all requirements here. And just like bootmem on Linux side, so its
>>> a little complicated to implement this entirely. So I prefer not to
>>> introduce this way in current phase.
>
Note here I don't address your comments above since I think we should
achieve an agreement firstly.
I think bitmap mechanism is a good idea but honestly, its not easy to
cover all requirements here. And just like bootmem on Linux side, so its
a little complicated to implement this entirely. S
>>> On 14.07.15 at 08:39, wrote:
>> > -} *resource, mem_resource, high_mem_resource, io_resource;
>>> +} *resource, mem_resource, high_mem_resource, io_resource,
> exp_mem_resource;
>>
>> Despite having gone through description and the rest of the patch I
>> can't seem to be able to guess
-} *resource, mem_resource, high_mem_resource, io_resource;
+} *resource, mem_resource, high_mem_resource, io_resource,
exp_mem_resource;
Despite having gone through description and the rest of the patch I
can't seem to be able to guess what "exp_mem" stands for.
Meaningful variable nam
>>> On 09.07.15 at 07:33, wrote:
> @@ -50,17 +75,22 @@ void pci_setup(void)
> /* Resources assignable to PCI devices via BARs. */
> struct resource {
> uint64_t base, max;
> -} *resource, mem_resource, high_mem_resource, io_resource;
> +} *resource, mem_resource, high_me
When allocating mmio address for PCI bars, we need to make
sure they don't overlap with reserved regions.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Signed-off-by: Tiejun Chen
---
v6 ~ v7:
* Nothing is changed.
v5
34 matches
Mail list logo