On 10/7/2015 7:16 PM, Wei Liu wrote:
Hi all
I'm pleased to announce that Xen 4.6 is released. As release manager I
would like to thank everyone who involved in the making of 4.6 release
(either in the form of patch, bug report or packaging effort). This
release wouldn't have happened without all
Sep 2015, Chen, Tiejun wrote:
Stefano,
I have two questions,
#1. Which qemu version is this igd stuff going into? 2.6?
#2. Is this igd stuff going into qemu-xen inside xen? Any plan to go into xen
4.6?
Thanks
Tiejun
On 9/9/2015 1:21 AM, Stefano Stabellini wrote:
> The following changes si
Ping...
Thanks
Tiejun
On 9/18/2015 4:30 PM, Tiejun Chen wrote:
Ian,
As we discussed previously,
http://patchwork.ozlabs.org/patch/457055/
now it's time to push this into on xen/tools side since all qemu stuffs
have been merged.
https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg02094.
On 9/23/2015 11:56 PM, Elena Ufimtseva wrote:
Hi
There is a regression in RMRR patch 5ae03990c120a7b3067a52d9784c9aa72c0705a6 in
new set_identity_p2m_entry. RMRRs are not being mapped in IOMMU for PVH Dom0.
This causes pages faults and some long 'hang-like' delays during boot and
device assignme
Stefano,
I have two questions,
#1. Which qemu version is this igd stuff going into? 2.6?
#2. Is this igd stuff going into qemu-xen inside xen? Any plan to go
into xen 4.6?
Thanks
Tiejun
On 9/9/2015 1:21 AM, Stefano Stabellini wrote:
The following changes since commit 8611280505119e296757a60
On 9/15/2015 7:00 PM, Paolo Bonzini wrote:
On 15/09/2015 11:55, Stefano Stabellini wrote:
On Mon, 14 Sep 2015, Paolo Bonzini wrote:
> On 10/09/2015 12:29, Stefano Stabellini wrote:
> > +if (lseek(config_fd, pos, SEEK_SET) != pos) {
> > +return -errno;
> > +}
> > do {
> >
But looks its not better, so any idea?
Did you at least make an attempt to find other examples of where
we dynamically determine the log level to be used for a message?
I would assume that if you did, you'd have come to
printk(XENLOG_GUEST "%s" VTDPREFIX
I didn't know this tip on
OK, that explanation is fine to me as long as it's made clear no
security guarantee once admin uses 'relax' for any domain. Tiejun
could you resend patch with right warning/error type?
Sure, but a little bit makes me confused when I'm trying to address
this. Actually most messages are same, ex
>> > > However I don't think this patch is a right fix. So far relax/strict
policy
>> > > is per-domain. what about one VM specifies relax while another VM
>> > > specifies strict when each is assigned with a device sharing rmrr
>> > > with the other? In that case it becomes a system-wide securit
> > Need to have separate warning/error level for relax/strict.
> >
> > However I don't think this patch is a right fix. So far relax/strict policy
> > is per-domain. what about one VM specifies relax while another VM
> > specifies strict when each is assigned with a device sharing rmrr
> > with t
Right, that's one of the things that would need taking care of.
(Whether enforcing an upper limit is actually needed I'm not
sure - we generally allow the admin to shoot himself in the foot
if he wants to. And whether the lower limit should be 64 instead
of just ensuring the limit is not zero is a
Thanks! I'll fold it the offending patch
(http://marc.info/?l=qemu-devel&m=144174596628052&w=2) and resend.
Reviewed-by: Michael S. Tsirkin
Michale and Stefano,
Thanks a lot :)
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://li
xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH
was set by configure. That won't be the case on OSX or Windows, where
the Xen headers don't exist.
Okay. This actually shouldn't be enabled on Windows so what about this?
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
i
As you see this short log, "hw/pci-assign: split pci-assign.c", so this
means I just extract something from the original hw/i386/kvm/pci-assign.c,
and here so I just keep those original head files residing
hw/i386/kvm/pci-assign.c, and I didn't introduce anything new.
hw/i386/kvm/pci-assign.c is
Sort of (the patch has the intended effect, but for its size very
many rough edges).
I guess we need to amend the original parameter, once_mapping_mfns, like
this,
/* xen_once_mapping_mfns: memory mapping mfn bumbers once. */
unsigned int xen_once_mapping_mfns;
size_param("once_mapping_mfns"
Need to have separate warning/error level for relax/strict.
However I don't think this patch is a right fix. So far relax/strict policy
is per-domain. what about one VM specifies relax while another VM
specifies strict when each is assigned with a device sharing rmrr
with the other? In that case
If the 64 limit was arbitrary then I would suggest increasing it to at least
1024 so that
at least 4M of BAR can be mapped in one go and it reduces the overhead by a
factor of 16.
1024 may be a little much, but 256 is certainly a possibility, plus
Konrad's suggestion to allow this limit to be co
On 9/9/2015 2:54 PM, Jan Beulich wrote:
On 09.09.15 at 03:59, wrote:
@@ -2310,12 +2312,16 @@ static int intel_iommu_assign_device(
PCI_DEVFN2(bdf) == devfn &&
rmrr->scope.devices_cnt > 1 )
{
-printk(XENLOG_G_ERR VTDPREFIX
- " ca
On 9/10/2015 12:10 AM, Stefano Stabellini wrote:
On Wed, 9 Sep 2015, Stefano Stabellini wrote:
On Tue, 8 Sep 2015, Peter Maydell wrote:
> On 8 September 2015 at 18:21, Stefano Stabellini
> wrote:
> > The following changes since commit 8611280505119e296757a60711a881341603fa5a:
> >
> > target-m
On 9/9/2015 9:06 PM, Stefano Stabellini wrote:
On Tue, 8 Sep 2015, Peter Maydell wrote:
On 8 September 2015 at 18:21, Stefano Stabellini
wrote:
> The following changes since commit 8611280505119e296757a60711a881341603fa5a:
>
> target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +020
So can Xen change log level dynamically like Linux? If yes, we might
change this level temporarily while passing through IGD. If not, any
suggestion?
First of all you could boot without lowering the log level (non-debug
builds) or raising the log level ("loglvl=warning"; debug builds). But
Sor
All guys,
Sorry to raise a question to you since I'm not very sure how to deal
with this.
When I passthrough a device like IGD, I can see so many messages:
"memory_map:add:" and "memory_map:remove:"
since we have to add/remove all pages map residing PCI bar. Especially
as a graphic devi
On 9/6/2015 11:19 AM, Tamas K Lengyel wrote:
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 836aed5..038776a 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2310,12 +2310,16 @@ static int intel_iommu_ass
Sorry for this delay response because I was on vacation.
On 9/5/2015 5:52 AM, Tamas K Lengyel wrote:
On Fri, Sep 4, 2015 at 2:17 AM, Jan Beulich wrote:
>>> On 03.09.15 at 21:39, wrote:
> So this change in 4.6 prevents me from passing through devices that have
> worked previously with VT-d:
>
On 8/27/2015 7:03 PM, Konrad Rzeszutek Wilk wrote:
On Thu, Aug 27, 2015 at 11:06:30AM +0800, Chen, Tiejun wrote:
On 8/25/2015 10:43 PM, Konrad Rzeszutek Wilk wrote:
>On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
>>On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
>>>
On 8/27/2015 4:40 PM, Malcolm Crossley wrote:
On 27/08/15 03:59, Chen, Tiejun wrote:
This kind of issue is already gone.
https://www.mail-archive.com/xen-devel@lists.xen.org/msg32464.html
There is a bug in the code you refer to above which results in no IOMMU page
table
mappings being
On 8/27/2015 12:19 AM, Malcolm Crossley wrote:
On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote:
On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
Hi everyone,
I saw some people passingly mention this on the list before but just in
case
On 8/25/2015 10:43 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
>Hi everyone,
>I saw some people passingly mention this on the list before but just in
>case it has been missed, my serial is a
This kind of issue is already gone.
https://www.mail-archive.com/xen-devel@lists.xen.org/msg32464.html
Thanks
Tiejun
On 8/26/2015 11:49 PM, Malcolm Crossley wrote:
Add RMRR 1:1 IOMMU mappings to IOMMU page tables if EPT page table are not being
shared with the IOMMU.
This is a regression in b
On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
Hi everyone,
I saw some people passingly mention this on the list before but just in
case it has been missed, my serial is also being spammed with the following
printouts with both Xen 4.6 RC1 and the latest staging build:
...
(XEN) [VT-D]DMAR:[DMA Re
On 8/5/2015 7:25 PM, Wei Liu wrote:
On Wed, Aug 05, 2015 at 12:06:22PM +0100, Ian Campbell wrote:
On Wed, 2015-08-05 at 11:58 +0100, Wei Liu wrote:
> On Wed, Aug 05, 2015 at 11:48:55AM +0100, Ian Campbell wrote:
> > On Wed, 2015-08-05 at 11:43 +0100, Wei Liu wrote:
> > > On Wed, Aug 05, 2015 at
Jul 25 17:48:51.685107 (d1) BIOS map:
Jul 25 17:48:51.685145 (d1) ffe0-: Main BIOS
Jul 25 17:48:51.693030 (d1) *** HVMLoader bug at e820.c:262
Jul 25 17:48:51.693064 (d1) *** HVMLoader crashed.
Git blame shows that the change that crashes hvmloader was part of the
RMRR series.
Tieju
devices, hence
we can't change the syntax of that string.
This patch reinstate the original implementation of next_bdf to
preserve the original syntax. The last argument for xc_assign_device
is always 0.
Signed-off-by: Wei Liu
---
Cc: Tiejun Chen
Tiejun, are you actually using this python bi
Can you avoid the mention of DT in the comment please, since PCI will
eventually go that path. Something like "No flags are defined for ARM"
would suffice I think.
Works for me.
But in some way "0" also represents one valid flag. So what about this ?
No flags are defined for ARM so its always
Tiejun, please can you send a patch to fix this up. Please send just
a revised version of this patch. I think the rest of the series will
rebase just fine on top of it. (If I'm wrong then we will need to do
something more complex.)
Sorry to this.
On ARM side the flag field doesn't take
These cosmetic changes can be fixed by a follow-up patch.
If Jackson would like not to fix this directly in his tree, I can post
this a small patch but we'd better squash this into the predecessor just
as one commit.
Thanks
Tiejun
___
Xen-devel m
Ian,
This was supposed to be my responsibility to resend this series so
appreciate for your extra effort.
git branch here:
http://xenbits.xen.org/gitweb/?p=people/iwj/xen.git;a=summary
git://xenbits.xen.org/people/iwj/xen.git
base.rdm-v13..wip.rdm-v13
I pick all RMRR patches from
Ian,
Thanks for your effort.
A tiny change may be needed but I don't block this.
+libxl__xc_device_get_rdm(libxl__gc *gc,
+ uint32_t flag,
Since now we are sitting on xc_reserved_device_memory_map(, flags, xxx),
s/flag/flags may be better.
+
I intend to produce a git branch RSN.
On the staging? Tomorrow I can pull to check/test this.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
OOPS! Please refer to this version: (One miss changing flag to flags in
patch #11 although we can compile successfully.)
#1. To patch #8
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2991333..9c5ef8b 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libx
On 2015/7/22 22:04, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v11][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
Sounds you start to merge them into your tree?
But now Jan is trying to update patch #1 as you see. I think something
needs to be synced on
On 2015/7/22 21:24, Ian Jackson wrote:
Tiejun Chen writes ("[v11][PATCH 11/16] tools/libxl: detect and avoid conflicts with
RDM"):
Acked-by: Wei Liu
I have dropped Wei's ack on this from my git branch, as it was clearly
inappropriate to retain it. (v11 was acked by me, so there is no need
f
On 2015/7/22 21:03, Jan Beulich wrote:
On 22.07.15 at 14:55, wrote:
+#ifdef HAS_PASSTHROUGH
+case XENMEM_reserved_device_memory_map:
+{
+struct get_reserved_device_memory grdm;
+
+if ( unlikely(start_extent) )
+return -ENOSYS;
+
+
+#ifdef HAS_PASSTHROUGH
+case XENMEM_reserved_device_memory_map:
+{
+struct get_reserved_device_memory grdm;
+
+if ( unlikely(start_extent) )
+return -ENOSYS;
+
+if ( copy_from_guest(&grdm.map, compat, 1) ||
+ !com
Thanks for your clarification to me.
The solution to this is to be systematic in how you handle the email
based review of a series, not to add a further to the reviewer by using
IRC as well.
For example, here is how I handle review of a series I am working on:
I keep all the replies to a serie
On 2015/7/22 16:28, Jan Beulich wrote:
On 22.07.15 at 03:30, wrote:
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Acked-by: Wei Liu
Signed-off-by: Tiejun Chen
Reviewed-by: Kevin Tian
---
v11:
* Use GCNEW_ARRAY to replace libxl__malloc()
* #define pfn_to_paddrk is
On 2015/7/21 23:57, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
Sorry, I just ignore the line in brackets since I always think this kind
of thing is often not a big deal, and next time I should pay more
attent
On 2015/7/21 23:09, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
+static void
+add_rdm_entry(libxl__gc *gc, libxl_domain_config *d_config,
+ uint64_t rdm_start, uint64_t rdm_size, int
Just to your example,
libxl_domain_config cfg;
cfg.stuff = blah;
cfg.rdm.strategy = HOST;
libxl_domain_create_new(&cfg, &domid);
libxl_domain_destroy(domid);
Here looks you mean d_config->rdms would be changed, right? Currently
this shouldn't be allowed. But I think we need
But another answer would be to take the union of the specified
regions. That would be more complicated, because the union would have
to be computed.
if (d_config->rdms[i].start == rdm_start)
return;
That doesn't, of course, compute the union.
Sorry I don't
On 2015/7/21 20:33, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
[Ian Jackson:]
The most obvious answer to me would be that if an rdms array is
specified, the strategy should be ignored. That is how the auto
On 2015/7/21 19:11, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
I would add this check at the beginning of this function:
assert(!d_config->num_rdms && !d_config->rdms).
As Ian Campbell and I hav
The domain destroy would not change cfg at all.
Okay.
If not, I should double check this duplication so what about a return in
the case of duplicating one entry?
What I am looking for is a *decision* about what the right behaviour
is, backed up by a *rationale*.
The most obvious answer to
On 2015/7/21 19:11, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v10][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
I would add this check at the beginning of this function:
assert(!d_config->num_rdms && !d_config->rdms).
As Ian Campbell and I hav
+static void
+add_rdm_entry(libxl__gc *gc, libxl_domain_config *d_config,
+ uint64_t rdm_start, uint64_t rdm_size, int rdm_policy)
+{
+assert(d_config->num_rdms);
+
+d_config->rdms = libxl__realloc(NOGC, d_config->rdms,
+d_config->num_rdms * sizeof(
On 2015/7/21 18:41, Ian Jackson wrote:
I wrote:
If the domain configuration has rdms and num_rdms already set, then
the strategy should presumably be ignored. (Passing the same domain
configuration struct to libxl_domain_create_new, after destroying the
domain, ought to work, even after the fir
But d_config is a libxl_domain_config which is supplied by libxl's
caller. It might contain some rdms.
I guess this line make you or other guys confused so lets delete this
line directly.
I don't think I am very confused.
And if you still worry about something, I can add assert() at the
beg
> I think the confusion here is that the d_config->rdms array (which
num_rdms is the length of) is in the public API (because it is in
libxl_types.idl) but is apparently only being used in this series as an
internal state for the domain build process (i.e. xl doesn't ever add
anything to the arr
I hope the following can address all comments below:
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 2f8e590..a4bd2a1 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -407,7 +407,7 @@ int libxl__domain_build(libxl__gc *gc,
switch (info-
Okay, I regenerate this patch online. And I just hope its good to be
acked here:
Provided it also works,
Reviewed-by: Jan Beulich
Why is this marked as Acked-by this time? The same question is raised to
another hvmloader patch as well.
This really makes me confused since you're the key ma
+int libxl__domain_device_construct_rdm(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint64_t rdm_mem_boundary,
+ struct xc_hvm_build_args *args)
+{
...
+/* Query all RDM en
Note I need more time to address others.
+int libxl__domain_device_construct_rdm(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint64_t rdm_mem_boundary,
+ struct xc_hvm_build_a
Looks just a little bit should be changed so I also paste this new
online to try winning your Acked here,
hvmloader/e820: construct guest e820 table
Now use the hypervisor-supplied memory map to build our final e820 table:
* Add regions for BIOS ranges and other special mappings not in the
h
On 2015/7/20 22:16, Jan Beulich wrote:
On 20.07.15 at 16:10, wrote:
Hmm... although I suppose that doesn't catch the possibility of a memory
range crossing the 4G boundary.
I think we can safely ignore that - both real and virtual hardware have
special regions right below 4Gb, so neither RAM
+/* Find the lowest RMRR higher than base. */
+static int find_next_rmrr(uint32_t base)
+{
+unsigned int i;
+int next_rmrr = -1;
+uint64_t min_base = (1ull << 32);
+
+for ( i = 0; i < memory_map.nr_map ; i++ )
+{
+if ( memory_map.map[i].type == E820_RESERVED &&
+
For clarity:
I am not acking this patch, primarily because I am not happy with the
code in xlu_rdm_parse which is (a) the result of repeated
clone-and-hack and (b) consists of ad-hoc string pointer fiddling.
Yes, I knew you mentioned this previously but I also remember our last
deal was someth
Actually, now that you mention it -- this should probably happen
instead when we update hvm_info->{low,high}_mem_pgend.
I also considered this point previously but I thought just right now we only
update hvm_info->low/high_mem_pgend inside pci_setup(). But you can't
guarantee this would be a so
v10:
* Instead of correcting e820, I'd like to correct memory_map.map[]
and then copy them into e820 directly. I think this can make sure
hvm_info, memory_map.map[] and e820 are on the same page.
Actually, now that you mention it -- this should probably happen
instead when we update hvm_i
One brief request -- if you do end up sending this series again, can
you please rebase to staging? This is the second time I've had to
manually fix up some patches so that they apply.
Sorry for this inconvenience.
Thanks
Tiejun
___
Xen-devel mailin
Before you add memory_map.nr_map, you should be able to iterate
from 0 to (not inclusive) nr. At least as far as I recall the original
patch.
Sorry, I really don't understand what you want.
Before we add memory_map.nr_map, e820[0, nr) don't include low/high
memory, right?
Why? memory_map is
On 2015/7/18 0:06, Jan Beulich wrote:
On 17.07.15 at 17:54, wrote:
+for ( i = nr-1; i > memory_map.nr_map; i-- )
Before you add memory_map.nr_map, you should be able to iterate
from 0 to (not inclusive) nr. At least as far as I recall the original
patch.
Sorry, I really don't understa
+for ( i = nr-1; i > memory_map.nr_map; i-- )
Before you add memory_map.nr_map, you should be able to iterate
from 0 to (not inclusive) nr. At least as far as I recall the original
patch.
Sorry, I really don't understand what you want.
Before we add memory_map.nr_map, e820[0, nr) don't i
I think Andrew means you (or someone else) improves that algorithm
later. No need to provide a perfect solution next week.
Yes, I understand what he mean. But I still want to further ask if he
have such a good idea right now, maybe we can try to address that
directly :)
Thanks
Tiejun
_
The PCI allocation code is in a state, but it was in a similarly bad
state before. I agree with Jan's point of the risk that these new
changes cause a regression in booting guests, although we can mitigate
that somewhat by testing.
I feel at this point that we shouldn't block the RMRR bugfix on
On 2015/7/17 18:50, Jan Beulich wrote:
On 17.07.15 at 11:09, wrote:
And then of course there's the question of whether "nr" is really
the right upper loop bound here: Just prior to this you added
the hypervisor supplied entries - why would you need to iterate
over them here? I.e. I'd see this b
My main disagreement here continues to be that we're talking
about a bug fix, and hence I don't view this as needing a freeze
exception in the first place (at least not at this point in time). Yes,
the bug fix involves adding code that looks like a new feature, but
that happens with bug fixes.
---
v9:
* A little improvement to code implementation but again, its still argued about
this solution.
And as said in reply to George's reply to v8 - the alternative he
proposed is still better than this one, and would therefore have
better chances of me agreeing to take what is there instea
Remind me again please - what prevents the highmem region from
colliding with hypervisor supplied entries?
Also, what if the resulting region exceeds the addressable range
(guest's view of CPUID[8008].EAX[0:7])?
Any idea to this? I think this issue also exists previously.
Thanks
Tiejun
__
* On hvmloader side, there three patches now:
patch #5 is reviewed by George and Acked by Jan;
patch #6 is reviewed just for code implementation but that solution can't
convince all maintainers. Honestly, this is a rare possibility of collision
in real world and the original pci allocation i
The way it's written I take it that you assume there to be exactly
one region that the adjustment needs to be done for. Iirc this is
correct with the current model, but why would you continue the
loop then afterwards? Placing a "break" in the if()'s body would
document the fact that only one such
On 2015/7/14 17:29, Wei Liu wrote:
On Tue, Jul 14, 2015 at 09:27:17AM +0800, Chen, Tiejun wrote:
Please work with maintainers to get those hvmloader patches acked or
reviewed.
I will do.
Maybe I need to update current status today.
I just send out v8:
* All tools comments raised by
not a efficient
way which can be put into 4.6. So instead, could your guys help me make
that better gradually to reach our current requirement as possible?
Thanks
Tiejun
On 2015/7/17 0:40, George Dunlap wrote:
On 07/16/2015 05:08 PM, Chen, Tiejun wrote:
On 2015/7/16 23:39, George Dunlap wrote
base = (resource->base + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+
+/* If we're using mem_resource, check for RMRR conflicts */
+while ( resource == &mem_resource &&
+next_rmrr > 0 &&
+check_overlap(base, bar_sz,
+
On 2015/7/16 23:39, George Dunlap wrote:
On 07/16/2015 04:20 PM, Chen, Tiejun wrote:
What about this?
Looks reasonable (but don't forget that I continue to be unconvinced
that the patch as a whole makes sense).
Yes, I always keep this in my mind as I mentioned in patch #00. Any risk
y
Honestly I didn't try to change that point but maybe I'm missing something?
Yes, you are missing something. :-) I told you exactly what I wanted
changed and what I said could remain the same:
By all means, calculate high_mem_end so it's easier to read. But then,
when creating a new region, s
On 2015/7/16 23:16, George Dunlap wrote:
On 07/16/2015 04:04 PM, Chen, Tiejun wrote:
Yes, sorry, add_high_mem will be the size of memory *relocated*, not
the actual end of it (unless, as you say, the original highmem region
didn't exist).
What I really meant was that either way,
What about this?
Looks reasonable (but don't forget that I continue to be unconvinced
that the patch as a whole makes sense).
Yes, I always keep this in my mind as I mentioned in patch #00. Any risk
you're still concerning? Is it that case if guest OS force enabling
these devices again? IMO,
Yes, sorry, add_high_mem will be the size of memory *relocated*, not
the actual end of it (unless, as you say, the original highmem region
didn't exist).
What I really meant was that either way, after adjusting the highmem
region in the e820, the end of that region should correspond to
hvm_info->
> Except that this isn't valid C (no statement following the label). I can
accept goto-s for some error handling cases where the alternatives
might be considered even more ugly than using goto. But the way
this or your original proposal look, I'd rather not have goto-s used
like this.
What ab
Here what I intended to do is if one of all bars specific to one given
device already conflicts with RDM, its not necessary to continue check other
remaining bars of this device and other RDM regions, we just disable this
device simply then check next device.
I know what you're trying to do; wha
+/*
+ * And then we also need to adjust highmem.
+ */
+if ( add_high_mem )
+{
+for ( i = 0; i < nr; i++ )
+{
+if ( e820[i].type == E820_RAM &&
+ e820[i].addr == (1ull << 32))
+{
+e820[i].size += add_high_me
+for ( i = 0; i < memory_map.nr_map ; i++ )
+{
+if ( memory_map.map[i].type != E820_RAM )
Here we're assuming that any region not marked as RAM is an RMRR. Is that true?
In any case, it would be just as strange to have a device BAR overlap
with guest RAM
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", whi
It looks like most of the libxl/libxc patches have been acked. It
seems to me that most of the hypervisor patches (1-3, 14-15) are
either ready to go in or pretty close.
Now that I looked over v8 I have to admit that if I was a tools
maintainer I wouldn't want to see some of the tools patches i
On 2015/7/16 15:55, Jan Beulich wrote:
On 10.07.15 at 16:50, wrote:
On Thu, Jul 9, 2015 at 6:33 AM, Tiejun Chen wrote:
v7:
It looks like most of the libxl/libxc patches have been acked. It
seems to me that most of the hypervisor patches (1-3, 14-15) are
either ready to go in or pretty clos
On 2015/7/16 15:40, Jan Beulich wrote:
On 16.07.15 at 08:52, wrote:
@@ -1577,9 +1578,15 @@ int iommu_do_pci_domctl(
seg = machine_sbdf >> 16;
bus = PCI_BUS(machine_sbdf);
devfn = PCI_DEVFN2(machine_sbdf);
+flag = domctl->u.assign_device.flag;
+if (
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
I think I would say:
--
Now use the hypervisor-supplied memory map to build our final e820 table:
* Add regions for BIOS ranges and other special mappings not in the
hypervisor map
* Add in the hypervisor regions
* Adjust the lowmem and highmem regions if we've had to relocate
memory (adding a hi
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 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
1 - 100 of 419 matches
Mail list logo
