On 2015/7/16 17:40, George Dunlap wrote:
On Thu, Jul 16, 2015 at 3:05 AM, Chen, Tiejun tiejun.c...@intel.com 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
On Thu, Jul 16, 2015 at 3:05 AM, Chen, Tiejun tiejun.c...@intel.com 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?
On 2015/7/16 0:14, George Dunlap wrote:
On Wed, Jul 15, 2015 at 2:56 PM, George Dunlap
george.dun...@eu.citrix.com 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
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, tiejun.c...@intel.com 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
On 15.07.15 at 06:27, tiejun.c...@intel.com 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
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,
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 15.07.15 at 02:55, tiejun.c...@intel.com 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
On 15.07.15 at 10:59, tiejun.c...@intel.com wrote:
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, tiejun.c...@intel.com 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
On 2015/7/15 19:05, George Dunlap wrote:
On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich jbeul...@suse.com wrote:
On 15.07.15 at 10:59, tiejun.c...@intel.com wrote:
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, tiejun.c...@intel.com wrote:
Furthermore, could we have this
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
On 2015/7/15 19:27, Jan Beulich wrote:
On 15.07.15 at 13:05, george.dun...@eu.citrix.com 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
On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich jbeul...@suse.com wrote:
On 15.07.15 at 10:59, tiejun.c...@intel.com wrote:
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, tiejun.c...@intel.com wrote:
Furthermore, could we have this solution as follows?
Yet more special casing
On 15.07.15 at 12:34, tiejun.c...@intel.com 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
On 15.07.15 at 13:05, george.dun...@eu.citrix.com 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
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 jbeul...@suse.com wrote:
On 15.07.15 at 10:59, tiejun.c...@intel.com wrote:
On 2015/7/15 16:34, Jan Beulich wrote:
On 15.07.15 at 06:27, tiejun.c...@intel.com
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 13:05, george.dun...@eu.citrix.com wrote:
On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich jbeul...@suse.com wrote:
On 15.07.15 at 10:59, tiejun.c...@intel.com wrote:
What about this?
@@ -301,6 +301,19 @@ void pci_setup(void)
pci_mem_start = 1;
}
+for
On 07/15/2015 12:24 PM, Jan Beulich wrote:
On 15.07.15 at 13:05, george.dun...@eu.citrix.com wrote:
On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich jbeul...@suse.com wrote:
On 15.07.15 at 10:59, tiejun.c...@intel.com wrote:
What about this?
@@ -301,6 +301,19 @@ void pci_setup(void)
On 15.07.15 at 15:40, dunl...@umich.edu wrote:
On Mon, Jul 13, 2015 at 2:12 PM, Jan Beulich jbeul...@suse.com 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
On Wed, Jul 15, 2015 at 2:56 PM, George Dunlap
george.dun...@eu.citrix.com 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
On Wed, Jul 15, 2015 at 09:32:34AM +0100, Jan Beulich wrote:
On 15.07.15 at 02:55, tiejun.c...@intel.com 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
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
On Mon, Jul 13, 2015 at 2:12 PM, Jan Beulich jbeul...@suse.com 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
On Wed, Jul 15, 2015 at 3:00 PM, Jan Beulich jbeul...@suse.com wrote:
On 15.07.15 at 15:40, dunl...@umich.edu wrote:
On Mon, Jul 13, 2015 at 2:12 PM, Jan Beulich jbeul...@suse.com wrote:
Therefore I'll not make any further comments on the rest of the
patch, but instead outline an allocation
On 14.07.15 at 08:39, tiejun.c...@intel.com 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
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.
On 14.07.15 at 12:54, tiejun.c...@intel.com 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
-} *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
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
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
On 09.07.15 at 07:33, tiejun.c...@intel.com 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,
32 matches
Mail list logo
