flight 36524 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 35697
Tests which did not
After commit 6d896e13, we should pass -errno on read failure.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
tools/libxl/libxl_aoutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 0d4c8af..b93f0e4
On 03/20/2015 02:38 AM, Waiman Long wrote:
On 03/19/2015 06:01 AM, Peter Zijlstra wrote:
[...]
You are probably right. The initial apply_paravirt() was done before the
SMP boot. Subsequent ones were at kernel module load time. I put a
counter in the __native_queue_spin_unlock() and it
Some change commited to staging earlier this week breaks ocaml bindings,
as shown below. I think it was introduced between
a68d1b65bb1bbb9b8db2d82695d32ac09c52a2d7..d4ea77c9d7b314001ff4e2eb7618b45f11551371:
NotImplementedError: Cannot handle KeyedUnion fields which are not Structs
But now that
On 03/20/2015 08:17 AM, Wen Congyang wrote:
After commit 6d896e13, we should pass -errno on read failure.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
tools/libxl/libxl_aoutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_aoutils.c
On 03/20/2015 04:25 PM, Ross Lagerwall wrote:
On 03/20/2015 08:17 AM, Wen Congyang wrote:
After commit 6d896e13, we should pass -errno on read failure.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
tools/libxl/libxl_aoutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, 2015-03-19 at 14:54 -0400, Konrad Rzeszutek Wilk wrote:
On Thu, Mar 19, 2015 at 04:47:58PM +, Ian Campbell wrote:
On Wed, 2015-03-18 at 20:24 -0400, Konrad Rzeszutek Wilk wrote:
Instead of assuming everything is always OK. We stash
the gpfns value as an parameter.
On Fri, 2015-03-20 at 18:08 +0800, Chen, Tiejun wrote:
+if (!xlu_cfg_get_string(config, gfx_passthru_kind, buf, 0)) {
+if (libxl_gfx_passthru_kind_from_string(buf,
+
b_info-u.hvm.gfx_passthru_kind)) {
+fprintf(stderr,
+ERROR:
I think this patch is identical to the one I just acked.
FWIW in the future there is no need to submit the same patch multiple
times. We will ask you to resend if it is necessary.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Tue, Mar 03, 2015 at 12:08:04PM +, Ian Campbell wrote:
I wouldn't recommend testing it yet until I've at least smoke tested
it to see that things still work if you don't cancel them.
Would review of the series be useful and/or appreciated at this stage?
Perhaps the first half
On Fri, Mar 20, 2015 at 12:08:48PM +0200, Vitaly Chernooky wrote:
On Fri, Mar 20, 2015 at 6:04 AM, Marek Marczykowski-Górecki
marma...@invisiblethingslab.com wrote:
On Thu, Mar 19, 2015 at 03:10:49PM +0200, Vitaly Chernooky wrote:
David,
On Thu, Mar 19, 2015 at 3:00 PM, David
On Fri, 2015-03-20 at 09:10 +0100, Olaf Hering wrote:
Some change commited to staging earlier this week breaks ocaml bindings,
as shown below. I think it was introduced between
a68d1b65bb1bbb9b8db2d82695d32ac09c52a2d7..d4ea77c9d7b314001ff4e2eb7618b45f11551371:
NotImplementedError: Cannot
On Fri, 2015-03-20 at 09:04 +0800, Chen, Tiejun wrote:
Refactor again,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8599a6a..05c8916 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -409,6 +409,23 @@ static char *dm_spice_options(libxl__gc *gc,
On Fri, 2015-03-20 at 00:41 +0100, HANNAS YAYA Issa wrote:
when I compile xen the timer run only once.
I believe Xen timers are one-shot only. If you want a periodic timer
then you will need to rearm it at the end of your handler.
Check the plt_overflow_timer for an example of this sort of
On 19.03.15 at 20:29, julien.gr...@linaro.org wrote:
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -187,6 +187,32 @@ void iommu_teardown(struct domain *d)
tasklet_schedule(iommu_pt_cleanup_tasklet);
}
+int iommu_construct(struct domain *d)
+{
+
On 19.03.15 at 20:29, julien.gr...@linaro.org wrote:
@@ -344,6 +344,13 @@ int iommu_do_domctl(
ret = iommu_do_pci_domctl(domctl, d, u_domctl);
#endif
+#ifdef HAS_DEVICE_TREE
+if ( ret != -ENODEV)
+return ret;
+
+ret = iommu_do_dt_domctl(domctl, d, u_domctl);
On Fri, 2015-03-20 at 11:03 +, Ian Campbell wrote:
Do the new callers actually need the number of bytes read/written or was
this just something which seemed like a good idea since it was in hand?
If it isn't needed
In fact, irrespective of the needs of the future callers lets go back to
David,
On Fri, Mar 20, 2015 at 12:46 PM, David Vrabel david.vra...@citrix.com wrote:
On 20/03/15 10:38, Vitaly Chernooky wrote:
So I have finished my investigation and suggest to discuss the simple
attaches patch.
Looks ok to me. But this needs to go via the filesystem maintainers,
Cc'ing
flight 36522 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10 fail REGR. vs. 35893
On 03/19/2015 08:56 AM, Ian Campbell wrote:
On Tue, 2015-03-10 at 08:16 -0400, Quan Xu wrote:
@@ -151,6 +152,8 @@ device_hardware_setup(void)
esp_scsi_setup();
megasas_setup();
pvscsi_setup();
+if (runningOnXen())
+vtpm4hvm_setup();
Is there anything which is
On 20/03/15 10:38, Vitaly Chernooky wrote:
So I have finished my investigation and suggest to discuss the simple
attaches patch.
Looks ok to me. But this needs to go via the filesystem maintainers,
Cc'ing Linus on it. You should explain the deadlock in more detail in
the commit message and
On Fri, 2015-03-20 at 16:17 +0800, Wen Congyang wrote:
After commit 6d896e13, we should pass -errno on read failure.
Hrm, this means that 6d896e13 was a more subtle interface change than I
was expecting (I'd forgotten that errno wasn't negative in userspace).
This means that someone needs to
On 03/10/2015 08:14 AM, Quan Xu wrote:
make sure QEMU machine class is initialized and QEMU has registered
Xen stubdom vTPM driver when call tpm_init()
Signed-off-by: Quan Xu quan...@intel.com
---
vl.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
On 3/7/2015 at 12:50 AM, in message
caflbxzzfzl2f4qnuwgbpza8v1ffgvvkbgn+gco6ceekvbf6...@mail.gmail.com, George
Dunlap george.dun...@eu.citrix.com wrote:
On Mon, Jan 19, 2015 at 8:28 AM, Chunyan Liu cy...@suse.com wrote:
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index
flight 36551 xen-4.3-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36551/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386none executed queued
On Thu, 2015-03-19 at 11:50 -0600, Charles Arnold wrote:
Whether the interface exists (even in buggy form) or not in older
versions is important because if it doesn't exist then that would be a
build failure, which we would want to avoid.
Right. The tree feature was added in version 2.0.0
On Thu, 2015-03-19 at 13:20 -0600, Charles Arnold wrote:
On 3/19/2015 at 12:09 PM, Anthony PERARD anthony.per...@citrix.com
wrote:
On Wed, Mar 18, 2015 at 04:12:26PM +, Ian Campbell wrote:
My second concern here is with the use of /var/run/xen/qmp-libxl-%i from
outside of libxl. I
+case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
+LOG(ERROR, unable to detect required gfx_passthru_kind);
In this case you will now have logged twice. I'd suggest logging only
here and not in the helper.
+default:
And this case is subtly different to
On Fri, Mar 20, 2015 at 6:04 AM, Marek Marczykowski-Górecki
marma...@invisiblethingslab.com wrote:
On Thu, Mar 19, 2015 at 03:10:49PM +0200, Vitaly Chernooky wrote:
David,
On Thu, Mar 19, 2015 at 3:00 PM, David Vrabel david.vra...@citrix.com
wrote:
On 19/03/15 12:10, Iurii
On Thu, Mar 19, 2015 at 12:55:12PM +, PRAMOD DEVENDRA wrote:
From: Pramod Devendra pramod.deven...@citrix.com
1. Make sure sun_path does not overflow
2. Close qmp_fd on error
3. Use goto out for error handling
Signed-off-by: Pramod Devendra pramod.deven...@citrix.com
CC: Ian Jackson
On Thu, Mar 19, 2015 at 05:51:15AM +, Koushik Chakravarty wrote:
Signed-off-by: Koushik Chakravarty koushik.chakrava...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Stefano Stabellini stefano.stabell...@eu.citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Wei Liu
From: Luis R. Rodriguez mcg...@suse.com
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails.
ioremap_wc() API is already used to take advantage of architecture
write-combining when available.
Convert the driver
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR and ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a)
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a)
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
When a system has PAT support enabled you don't need to be
using MTRRs. Andy had added arch_phys_wc_add() long ago to
help with this but not all drivers were converted
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When ballooning large amounts of memory
from dom0, freemem()
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few exceptions
to this, one is where device drivers are known to exist
on PATs with errata, another situation is observed on
old device drivers where devices had
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
From: Luis R. Rodriguez mcg...@suse.com
The size of the framebuffer to be used needs to
be fudged to account for the different type of
devices that are out there. This captures what
is required to do well, we'll resuse this later.
This has no functional changes.
Cc: Suresh Siddha
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
Hello Vijay,
On 19/03/2015 14:38, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Virtual ITS command processing support to
Virtual ITS driver. Also add API's to in physical
ITS driver to send commands from Virtual ITS driver.
In this patch, following
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
When a system has PAT support enabled you don't need to be
using MTRRs. Andy had added arch_phys_wc_add() long ago to
help with this but not all drivers were converted over. We
have to take care to only convert drivers where we know that
the proper
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases() just
peg an IORESOURCE_WC flag for us but where exactly
video devices memory lie varies *largely* and at times things
are mixed with MMIO registers,
From: Luis R. Rodriguez mcg...@suse.com
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Dennis Dalessandro dennis.dalessan...@intel.com
Cc: Mike Marciniszyn
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same ioremap()'d area for the MTRR.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few exceptions
to this, one is where device drivers are known to exist
on
From: Luis R. Rodriguez mcg...@suse.com
The MTRR added was never being deleted.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache()
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of
From: Luis R. Rodriguez mcg...@suse.com
There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a)
From: Luis R. Rodriguez mcg...@suse.com
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
to kick through fully functionally. This can happen
for instance on Xen where MTRR is not supported but
PAT is, this can happen now on Linux as of
From: Luis R. Rodriguez mcg...@suse.com
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi
From: Luis R. Rodriguez mcg...@suse.com
This driver never removed the MTRRs. Fix that.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc:
From: Luis R. Rodriguez mcg...@suse.com
The same area used for MTRR is used for the ioremap() area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
flight 36527 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36527/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 36516
Tests which did not
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
The crusade to replace mtrr_add() with architecture agnostic
arch_phys_wc_add() is complete, this will ensure write-combining
implementations (PAT on x86) is taken advantage instead of using
MTRR. With the crusade done now, hide direct MTRR access for
From: Luis R. Rodriguez mcg...@suse.com
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PCI
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
flight 36570 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
From: Luis R. Rodriguez mcg...@suse.com
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB,
the other MTRR types were implemented and supported here but with
no real good reason. The ioremap() APIs are architecture agnostic and
at least on x86 PAT is a new design that extends MTRRs
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be invalid instead of identity in the
p2m list before they can be added.
Fix some regressions introduced in 3.16 and 3.19.
Changes in V2:
- use range in Kconfig instead of BUILD_BUG_ON_MSG() as suggested by
Boris Ostrovsky and Paul Bolle
- simplify ifdeffery regarding P2M_LIMIT in patch 1 as requested by David Vrabel
- changed test for failure of
Commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear
virtual mapped sparse p2m list) introduced a regression regarding to
memory hotplug for a pv-domain: as the virtual space for the p2m list
is allocated for the to be expected memory size of the domain only,
hotplugged memory
Hi Vijay,
On 19/03/2015 14:37, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add ITS support for arm. Following major features
are supported
- GICv3 ITS support for arm64 platform
- Supports multi ITS node
- LPI descriptors are allocated on-demand
-
On Thu, Mar 19, 2015 at 05:54:03PM -0400, Boris Ostrovsky wrote:
xc_numainfo() is not expected to be used on a hot path and therefore
hypercall buffer management can be pushed into libxc. This will simplify
life for callers.
Also update error logging macros.
Signed-off-by: Boris Ostrovsky
On Fri, 2015-03-20 at 10:24 -0400, Boris Ostrovsky wrote:
On 03/20/2015 09:54 AM, Ian Campbell wrote:
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote:
+if (cputopo) {
+if ((ret = xc_hypercall_bounce_pre(xch, cputopo)))
I think this guy will tolerate a NULL here (and
-Original Message-
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: Friday, March 20, 2015 8:20 PM
To: Pang, LongtaoX
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com;
Hu, Robert
Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some
On Fri, 2015-03-20 at 10:10 -0400, Boris Ostrovsky wrote:
I actually think it's the other way around: when I made the first change
in 4/8 I added spaces, which this file's style generally doesn't use.
Which, conveniently, is different from the style used by xc_misc.c
Right, libxc uses the
On Thu, Mar 19, 2015 at 05:54:01PM -0400, Boris Ostrovsky wrote:
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Changes in v5:
* Increment ti-first_dev in the loop
* Make node in xen_sysctl_pcitopoinfo a uint32
*
On 03/20/2015 02:46 PM, Daniel Kiper wrote:
On Fri, Mar 20, 2015 at 01:55:39PM +0100, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were added via memory
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote:
A number of changes to XEN_SYSCTL_numainfo interface:
* Make sysctl NUMA topology query use fewer copies by combining some
fields into a single structure and copying distances for each node
in a single copy.
* NULL meminfo and
On Thu, Mar 19, 2015 at 05:53:57PM -0400, Boris Ostrovsky wrote:
SLIT values are byte-sized and some of them (0-9 and 255) have
special meaning. Adjust __node_distance() to reflect this and
modify scrub_heap_pages() and do_sysctl() to deal with
__node_distance() returning an invalid SLIT
On Fri, 2015-03-20 at 13:09 +0100, HANNAS YAYA Issa wrote:
Hi
Is it possible to swap out guest physical page from hypervisor in xen
The keyword you need in the context of Xen is paging not swap, with
that you should be able to find docs in the source tree and the wiki
etc.
Paging happens from
On Fri, 2015-03-20 at 12:09 +, Pang, LongtaoX wrote:
Add xen-devel in mail loop.
Here is what I wrong in reply to the private version without noticing
that it was private.
On Fri, 2015-03-20 at 11:59 +, Pang, LongtaoX wrote:
-Original Message-
From: Ian Campbell
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote:
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 411128e..607ae61 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -209,22 +209,49 @@ out:
return ret;
}
-int xc_numainfo(xc_interface *xch,
On 03/20/2015 09:56 AM, Ian Campbell wrote:
On Thu, 2015-03-19 at 17:54 -0400, Boris Ostrovsky wrote:
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 411128e..607ae61 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -209,22 +209,49 @@ out:
return ret;
}
On Fri, Mar 20, 2015 at 09:48:08AM +, Ian Campbell wrote:
On Thu, 2015-03-19 at 14:54 -0400, Konrad Rzeszutek Wilk wrote:
On Thu, Mar 19, 2015 at 04:47:58PM +, Ian Campbell wrote:
On Wed, 2015-03-18 at 20:24 -0400, Konrad Rzeszutek Wilk wrote:
Instead of assuming everything is
On 03/20/2015 02:44 PM, Boris Ostrovsky wrote:
On 03/20/2015 08:55 AM, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were added via memory hotplug to
a pv
1 - 100 of 192 matches
Mail list logo
