On Tue, Aug 25, 2015 at 08:45:07AM -0500, Doug Goldstein wrote:
> Per http://wiki.qemu.org/ChangeLog/1.0 and the fact that no currently
> supported distro ships the x86 system emulator binary as 'qemu', this
> changes the default when a user specifies --with-system-qemu without a
> PATH to 'qemu-sy
On Thu, Aug 27, 2015 at 12:55:56AM -0600, Jan Beulich wrote:
> Konrad,
>
> I thought I'd remind you of the "some progress per release" criteria
> to avoid it becoming subject to removal. The most recent changes
> date back to spring 2014 afaics...
>
I think it is a bit too late for any changes t
On Tue, Aug 25, 2015 at 01:58:42AM -0600, Jan Beulich wrote:
[...]
> (vmx_virtual_intr_delivery_enabled() is a good second example bogusly using
> int as its return type, and once adjusted to bool_t it would break)?
>
VMX maintainers, I think Jan is waiting for reply from you for that
particular
>>> On 27.08.15 at 02:37, wrote:
> On 20/08/2015 19:25, Shannon Zhao wrote:
>> On 2015/8/20 22:06, Jan Beulich wrote:
>>> So can the two of you please sort out whether these are Linux
>>> internal tags (which Xen has no business generating, or even
>>> knowing of) or some form of publicly document
>>> On 27.08.15 at 09:17, wrote:
> On Thu, Aug 27, 2015 at 12:55:56AM -0600, Jan Beulich wrote:
>> Konrad,
>>
>> I thought I'd remind you of the "some progress per release" criteria
>> to avoid it becoming subject to removal. The most recent changes
>> date back to spring 2014 afaics...
>>
>
>
On Thu, Aug 27, 2015 at 01:55:46AM -0600, Jan Beulich wrote:
> >>> On 27.08.15 at 09:17, wrote:
> > On Thu, Aug 27, 2015 at 12:55:56AM -0600, Jan Beulich wrote:
> >> Konrad,
> >>
> >> I thought I'd remind you of the "some progress per release" criteria
> >> to avoid it becoming subject to removal
On 08/27/2015 02:55 PM, Jan Beulich wrote:
> Konrad,
>
> I thought I'd remind you of the "some progress per release" criteria
> to avoid it becoming subject to removal. The most recent changes
> date back to spring 2014 afaics...
>
> Jan
>
AFAIR Konrad holds a few patches, I believe he will se
>>> On 26.08.15 at 16:44, wrote:
> El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
>> On 26/08/15 13:00, Jan Beulich wrote:
This structure is guaranteed to always be placed in memory after the
>>> DYM "These structures are ..."?
>>>
loaded kernel and modules.
>>
>> There is no require
flight 37844 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 37839
build-i
On NUMA systems, where we try to use node local memory for the basic
control structures of the buddy allocator, this special case needs to
take into consideration a possible address width limit placed on the
Xen heap. In turn this (but also other, more abstract considerations)
requires that xenheap
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 created if the guest domain is not sharing it's EP
flight 60864 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60864/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 60807
test-armhf-armhf-xl-cu
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 create
>>> On 26.08.15 at 17:49, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1839,8 +1839,16 @@ static int rmrr_identity_mapping(struct domain *d,
> bool_t map,
>
> while ( base_pfn < end_pfn )
> {
> -if
>>> On 27.08.15 at 11:05, 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 r
CC George (x86 MM maintainer)
On Thu, Aug 27, 2015 at 02:37:17AM -0600, Jan Beulich wrote:
> On NUMA systems, where we try to use node local memory for the basic
> control structures of the buddy allocator, this special case needs to
> take into consideration a possible address width limit placed
On 27/08/15 09:04, Jan Beulich wrote:
On 26.08.15 at 16:44, wrote:
>> El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
>>> On 26/08/15 13:00, Jan Beulich wrote:
> This structure is guaranteed to always be placed in memory after the
DYM "These structures are ..."?
> loaded k
El 27/08/15 a les 11.43, Andrew Cooper ha escrit:
> On 27/08/15 09:04, Jan Beulich wrote:
> On 26.08.15 at 16:44, wrote:
>>> El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
On 26/08/15 13:00, Jan Beulich wrote:
>> This structure is guaranteed to always be placed in memory after the
On 27/08/15 09:37, Jan Beulich wrote:
> On NUMA systems, where we try to use node local memory for the basic
> control structures of the buddy allocator, this special case needs to
> take into consideration a possible address width limit placed on the
> Xen heap. In turn this (but also other, more
On 08/18/2015 04:55 PM, Dario Faggioli wrote:
> Hey everyone,
>
> So, as a followup of what we were discussing in this thread:
>
> [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest
> http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03241.html
>
> I started looki
On 27/08/15 03:15, Jim Fehlig wrote:
> On 08/25/2015 04:40 AM, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> v2:
>> * %Revision and #History, following template review
>> * Grammar fixes
>> ---
>> docs/features/migration.pandoc | 100
>> +
On 27/08/15 03:44, Jim Fehlig wrote:
> On 08/25/2015 04:40 AM, Andrew Cooper wrote:
>> An issue which Xen has is an uncertain support statement for features.
>> Given the success seen with docs/misc/xen-command-line.markdown, and in
>> particular keeping it up to date, introduce a similar system fo
Manipulating the obj-> structures requires us to hold the
pool->rwlock lock. Lets make that obvious in this function to
catch any errant users (none found, but we may in future).
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/common/tmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/x
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/common/tmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 66d2852..9bd75d8 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2659,7 +2659,7 @@ long do_tmem_op(tmem_cli_op_t uo
It mentions it but it is never used. The hypercall interface
knows nothing of this sort of thing either. Lets just remove it.
Signed-off-by: Konrad Rzeszutek Wilk
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_tmem.c | 38 --
t
Hey!
At the Xenhackathon we spoke that the tmem code needs a bit of cleanups
and simplification. One of the things that Andrew mentioned was that the
TMEM_CONTROL should really be part of the sysctl hypercall. As I ventured
this path I realized there were some other issues that need to be taken
ca
The sysctl is where the tmem control operations are done and the
XSM checks are done via there. The old mechanism (to check
for control tmem op XSM from do_tmem_op) is not needed anymore.
CC: Daniel De Graaf
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/include/xsm/dummy.h | 6 -
My editor marks these in red glowing red so removing them to
make it easier to focus on code.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/common/tmem.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
inde
The operations are to be used by an control domain to set parameters,
list pools, clients, and to be used during migration.
There is no need to have them in the tmem hypercall path.
This patch moves code without adding fixes - and in fact in
some cases makes the parameters soo long that they hurt
We are doing another call to set_xen_guest_handle right
after the xc_hypercall_bounce_pre (the correct place to do it).
Signed-off-by: Konrad Rzeszutek Wilk
---
tools/libxc/xc_tmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/libxc/xc_tmem.c b/tools/libxc/xc_tmem.c
index 8352233..0
When we are using shared pools we have an global array
(on which we put the pool), and an array of pools per domain.
We also have an shared list of clients (guests) _except_
for the very first domain that created the shared pool.
To deal with multiple guests using an shared pool we have an
ref cou
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:
> >>>Hi everyone,
> >>>I saw some people passingly mention this on th
On Thu, Aug 27, 2015 at 04:02:08PM +0800, Bob Liu wrote:
>
> On 08/27/2015 02:55 PM, Jan Beulich wrote:
> > Konrad,
> >
> > I thought I'd remind you of the "some progress per release" criteria
> > to avoid it becoming subject to removal. The most recent changes
> > date back to spring 2014 afaics
On 25/08/15 03:14, Bob Liu wrote:
> Hi Rafal,
>
> Please have a try adding "--iodepth_batch=32 --iodepth_batch_complete=32" to
> the fio command line.
> I didn't see this issue any more, neither for domU.
>
> Thanks,
> -Bob
Hello,
Using 4.2-rc8 kernel, I can confirm that merges are happening aft
>>> On 27.08.15 at 11:57, wrote:
> El 27/08/15 a les 11.43, Andrew Cooper ha escrit:
>> On 27/08/15 09:04, Jan Beulich wrote:
>> On 26.08.15 at 16:44, wrote:
El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
> On 26/08/15 13:00, Jan Beulich wrote:
>>> This structure is guaranteed
This is a note to let you know that I have just added a patch titled
x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/lo
On Thu, Aug 27, 2015 at 07:01:59AM -0400, Konrad Rzeszutek Wilk wrote:
> It mentions it but it is never used. The hypercall interface
> knows nothing of this sort of thing either. Lets just remove it.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Wei Liu
__
On Thu, Aug 27, 2015 at 07:01:56AM -0400, Konrad Rzeszutek Wilk wrote:
[...]
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> xen/common/tmem.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
> index f2dc26e..572944e 100644
>
On Thu, Aug 27, 2015 at 07:02:00AM -0400, Konrad Rzeszutek Wilk wrote:
> The operations are to be used by an control domain to set parameters,
> list pools, clients, and to be used during migration.
>
> There is no need to have them in the tmem hypercall path.
>
> This patch moves code without ad
>>> On 20.07.15 at 16:29, wrote:
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and
> going down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because start lives on 1 MiB address. So,
Hello,
When using Intel hardware without shared page tables between the IOMMU
and EPT (I have not tried if the same happens when sharing the page
tables), the following crash happens if I press the 'o' debug key with
a HVM guest running. The guest doesn't have any device passed-through.
(XEN)
Hi all
Xen 4.6 RC2 has been tagged. You can check out the tag 4.6.0-rc2 in xen.git.
We notice that tarball build is broken so we don't provide RC2 tarball. RC1
tarball was broken, too. We will fix the tarball build problem for RC3.
When reporting bugs, please send your bug report to
xen-de...@li
>>> On 20.07.15 at 16:29, wrote:
> Signed-off-by: Daniel Kiper
For a patch of this size, no description at all seems rather
problematic.
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -89,6 +89,13 @@ multiboot1_header_end:
> 0, /* Number of the lines
On 27/08/15 12:29, Roger Pau Monné wrote:
> Hello,
>
> When using Intel hardware without shared page tables between the IOMMU
> and EPT (I have not tried if the same happens when sharing the page
> tables), the following crash happens if I press the 'o' debug key with
> a HVM guest running. The
>>> On 20.07.15 at 16:29, wrote:
> Current early command line parser implementation in assembler
> is very difficult to change to relocatable stuff using segment
> registers. This requires a lot of changes in very weird and
> fragile code. So, reimplement this functionality in C. This
> way code w
On 27/08/15 12:01, Konrad Rzeszutek Wilk wrote:
> It mentions it but it is never used. The hypercall interface
> knows nothing of this sort of thing either. Lets just remove it.
>
> Signed-off-by: Konrad Rzeszutek Wilk
It would be nice if you could take the opportunity of changing every
caller to
>>> On 20.07.15 at 16:29, wrote:
> - %fs register is filled with segment descriptor which describes memory
> region
> with Xen image (it could be relocated or not);
This is too fuzzy. Please be very precise which region it is that %fs
is supposed to point to (so that reviewers have a chanc
On 27/08/15 12:02, Konrad Rzeszutek Wilk wrote:
> @@ -1559,7 +1559,7 @@ refind:
> {
> /* no puts allowed into a frozen pool (except dup puts) */
> if ( client->frozen )
> - goto unlock_obj;
> + goto unlock_obj;
Need to lose 3 spaces he
On 27/08/15 12:01, Konrad Rzeszutek Wilk wrote:
> Hey!
>
> At the Xenhackathon we spoke that the tmem code needs a bit of cleanups
> and simplification. One of the things that Andrew mentioned was that the
> TMEM_CONTROL should really be part of the sysctl hypercall. As I ventured
> this path I rea
On 27/08/15 12:02, Konrad Rzeszutek Wilk wrote:
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1808,25 +1808,25 @@ static PyObject *pyxc_tmem_control(XcObject *self,
> &pool_id, &subop, &cli_id, &arg1, &arg2, &buf) )
> ret
flight 60877 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60877/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 14 guest-saverestore fail REGR. vs. 59254
test-amd64-i386-xl-xs
El 27/08/15 a les 14.02, Andrew Cooper ha escrit:
> On 27/08/15 12:29, Roger Pau Monné wrote:
>> Hello,
>>
>> When using Intel hardware without shared page tables between the IOMMU
>> and EPT (I have not tried if the same happens when sharing the page
>> tables), the following crash happens if I
On 2015/8/27 15:52, Jan Beulich wrote:
On 27.08.15 at 02:37, wrote:
On 20/08/2015 19:25, Shannon Zhao wrote:
On 2015/8/20 22:06, Jan Beulich wrote:
So can the two of you please sort out whether these are Linux
internal tags (which Xen has no business generating, or even
knowing of) or some
>>> On 27.08.15 at 13:29, wrote:
> When using Intel hardware without shared page tables between the IOMMU
> and EPT (I have not tried if the same happens when sharing the page
> tables), the following crash happens if I press the 'o' debug key with
> a HVM guest running. The guest doesn't have
Reported-by: Roger Pau Monné
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -411,7 +411,7 @@ static void iommu_dump_p2m_table(unsigne
ops = iommu_get_ops();
for_each_domain(d)
{
-if ( is_hardware_domain(d) )
+
With the addition of FMODE_ATOMIC_POS in the Linux 3.14 kernel,
concurrent blocking file accesses to a single open file descriptor can
cause a deadlock trying to grab the file position lock. If a watch has
been set up, causing a read_thread to blocking read on the file
descriptor, then future write
El 27/08/15 a les 16.01, Jan Beulich ha escrit:
On 27.08.15 at 13:29, wrote:
>> When using Intel hardware without shared page tables between the IOMMU
>> and EPT (I have not tried if the same happens when sharing the page
>> tables), the following crash happens if I press the 'o' debug key
>>> On 27.08.15 at 15:50, wrote:
> On 2015/8/27 15:52, Jan Beulich wrote:
>> One other aspect completely left off so far is that of proper isolation:
>> What x86 exposes to Dom0 is specifically limited to what Dom0 is
>> supposed to know. I'm getting the impression that by exposing more
>> EFI tab
On Thu, Aug 27, 2015 at 07:01:55AM -0400, Konrad Rzeszutek Wilk wrote:
> Hey!
>
> At the Xenhackathon we spoke that the tmem code needs a bit of cleanups
> and simplification. One of the things that Andrew mentioned was that the
> TMEM_CONTROL should really be part of the sysctl hypercall. As I ve
On 2015/8/27 22:13, Jan Beulich wrote:
On 27.08.15 at 15:50, wrote:
On 2015/8/27 15:52, Jan Beulich wrote:
One other aspect completely left off so far is that of proper isolation:
What x86 exposes to Dom0 is specifically limited to what Dom0 is
supposed to know. I'm getting the impression th
Thanks, this solves the problem.
El 27/08/15 a les 16.04, Jan Beulich ha escrit:
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Tested-by: Roger Pau Monné
Acked-by: Roger Pau Monné
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -411,7 +411,7
On Thu, Aug 27, 2015 at 08:04:19AM -0600, Jan Beulich wrote:
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
>
Release-acked-by: Wei Liu
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -411,7 +411,7 @@ static void iommu_dump_p2m_table(unsigne
>
Today trying xen 4.6.0-rc2 with all things needed for future production
server I found a regression: xl create fails if domU have custom vifname.
xl create test.cfg
Parsing config from test.cfg
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/vif-bridge add [14581]
On Tue, Aug 11, 2015 at 12:13 PM, Ian Jackson wrote:
> B "1(c)(maintainer)/2(a)/3(a)"
>
> Branch.
>
> Maintainers may choose to defer patch series based on risk of
> conflicts with bugfixes required for 4.6. Clear communication with
> submitters is required.
>
> Bugfixes for bugs in 4.6
On Thu, Aug 27, 2015 at 02:37:17AM -0600, Jan Beulich wrote:
> On NUMA systems, where we try to use node local memory for the basic
> control structures of the buddy allocator, this special case needs to
> take into consideration a possible address width limit placed on the
> Xen heap. In turn this
On Thu, Aug 27, 2015 at 04:41:46PM +0200, Fabio Fantoni wrote:
> Today trying xen 4.6.0-rc2 with all things needed for future production
> server I found a regression: xl create fails if domU have custom vifname.
> xl create test.cfg
> Parsing config from test.cfg
> libxl: error: libxl_exec.c:118:l
Add the appropriate #if checks around the kexec code in the x86 codebase
so that the feature can actually be turned off by the flag instead of
always required to be enabled on x86.
Signed-off-by: Jonathan Creekmore
---
xen/arch/x86/Makefile | 4 ++--
xen/arch/x86/apic.c
Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"):
> An issue which Xen has is an uncertain support statement for features.
> Given the success seen with docs/misc/xen-command-line.markdown, and in
> particular keeping it up to date, introduce a similar system for
> featur
>>> On 27.08.15 at 13:01, wrote:
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -915,6 +915,11 @@ static int obj_rb_insert(struct rb_root *root, struct
> tmem_object_root *obj)
> {
> struct rb_node **new, *parent = NULL;
> struct tmem_object_root *this;
> +struct tmem_poo
On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
> >>> On 20.07.15 at 16:29, wrote:
[...]
> > /* Copy bootstrap trampoline to low memory, below 1MB. */
> > -mov $sym_phys(trampoline_start),%esi
> > +lea sym_offset(trampoline_start)(%ebp),%esi
> >
>>> On 27.08.15 at 15:12, wrote:
> On 27/08/15 12:02, Konrad Rzeszutek Wilk wrote:
>> --- a/xen/include/xen/tmem.h
>> +++ b/xen/include/xen/tmem.h
>> @@ -9,6 +9,9 @@
>> #ifndef __XEN_TMEM_H__
>> #define __XEN_TMEM_H__
>>
>> +struct xen_sysctl_tmem_op;
>
> #include please.
Why? Forward declar
>>> On 27.08.15 at 13:02, wrote:
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> xen/common/tmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
> index 66d2852..9bd75d8 100644
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
>
>>> On 27.08.15 at 13:02, wrote:
> @@ -2666,9 +2662,9 @@ long do_tmem_op(tmem_cli_op_t uops)
> /* Acquire wirte lock for all command at first */
> write_lock(&tmem_rwlock);
>
> -if ( op.cmd == TMEM_CONTROL )
> +if ( op.cmd == TMEM_CONTROL_MOVED )
> {
> -rc = do_tme
>>> On 27.08.15 at 16:47, wrote:
> Add the appropriate #if checks around the kexec code in the x86 codebase
> so that the feature can actually be turned off by the flag instead of
> always required to be enabled on x86.
But you realize that these HAVE_* variables aren't meant to be used
for disab
On 27/08/15 15:47, Jonathan Creekmore wrote:
> Add the appropriate #if checks around the kexec code in the x86 codebase
> so that the feature can actually be turned off by the flag instead of
> always required to be enabled on x86.
>
> Signed-off-by: Jonathan Creekmore
In principle, this is a goo
On 27/08/15 15:47, Jonathan Creekmore wrote:
> Add the appropriate #if checks around the kexec code in the x86 codebase
> so that the feature can actually be turned off by the flag instead of
> always required to be enabled on x86.
What's your use case for this?
I think you should consider provid
>>> On 27.08.15 at 17:10, wrote:
> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > /* Copy bootstrap trampoline to low memory, below 1MB. */
>> > -mov $sym_phys(trampoline_start),%esi
>> > +lea sym_offset(tramp
>>> On 27.08.15 at 17:22, wrote:
> On 27/08/15 15:47, Jonathan Creekmore wrote:
>> @@ -812,7 +816,11 @@ ENTRY(hypercall_args_table)
>> .byte 2 /* do_hvm_op*/
>> .byte 1 /* do_sysctl*/ /* 35 */
>> .byte 1 /* do_domctl*/
>> +#ifdef CONF
>>> On 27.08.15 at 17:27, wrote:
> On 27/08/15 15:47, Jonathan Creekmore wrote:
>> @@ -125,6 +126,22 @@ do {\
>> cpu_relax();\
>> } \
On 27/08/15 15:52, Ian Jackson wrote:
> Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"):
>> An issue which Xen has is an uncertain support statement for features.
>> Given the success seen with docs/misc/xen-command-line.markdown, and in
>> particular keeping it up to da
On 27/08/15 16:34, Jan Beulich wrote:
On 27.08.15 at 17:22, wrote:
>> On 27/08/15 15:47, Jonathan Creekmore wrote:
>>> @@ -812,7 +816,11 @@ ENTRY(hypercall_args_table)
>>> .byte 2 /* do_hvm_op*/
>>> .byte 1 /* do_sysctl*/ /* 35 */
>>> .byte
From: Andy Lutomirski
This patch has been added to the 3.18 stable tree. If you have any
objections, please let us know.
===
[ Upstream commit aa1acff356bbedfd03b544051f5b371746735d89 ]
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Un
> On Aug 27, 2015, at 10:27 AM, David Vrabel wrote:
>
> On 27/08/15 15:47, Jonathan Creekmore wrote:
>> Add the appropriate #if checks around the kexec code in the x86 codebase
>> so that the feature can actually be turned off by the flag instead of
>> always required to be enabled on x86.
>
>
When we create a source code tarball, mini-os is extracted to
extras/mini-os directory. When building a source code tarball, we
shouldn't clone mini-os again.
Only clone mini-os when that directory doesn't exist. This fixes tarball
build and doesn't affect non-tarball build.
Signed-off-by: Wei Li
>>> On 13.08.15 at 20:12, wrote:
> @@ -777,7 +777,7 @@ int arch_set_info_guest(
>
> /* The context is a compat-mode one if the target domain is compat-mode;
> * we expect the tools to DTRT even in compat-mode callers. */
> -compat = is_pv_32bit_domain(d);
> +compat = is_pv_32b
>>> On 13.08.15 at 20:12, wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 27.08.15 at 17:54, wrote:
> When we create a source code tarball, mini-os is extracted to
> extras/mini-os directory. When building a source code tarball, we
> shouldn't clone mini-os again.
>
> Only clone mini-os when that directory doesn't exist. This fixes tarball
> build and doesn't af
On Thu, Aug 27, 2015 at 10:05:56AM -0600, Jan Beulich wrote:
> >>> On 27.08.15 at 17:54, wrote:
> > When we create a source code tarball, mini-os is extracted to
> > extras/mini-os directory. When building a source code tarball, we
> > shouldn't clone mini-os again.
> >
> > Only clone mini-os whe
On Thu, Aug 27, 2015 at 09:04:38AM -0500, Jonathan Creekmore wrote:
> With the addition of FMODE_ATOMIC_POS in the Linux 3.14 kernel,
> concurrent blocking file accesses to a single open file descriptor can
> cause a deadlock trying to grab the file position lock. If a watch has
> been set up, caus
On Thu, Aug 27, 2015 at 11:24 AM, George Dunlap
wrote:
> On 08/18/2015 04:55 PM, Dario Faggioli wrote:
>> Hey everyone,
>>
>> So, as a followup of what we were discussing in this thread:
>>
>> [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest
>> http://lists.xenproject.org/arch
Hi,
On 21/08/15 18:10, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 21, 2015 at 05:08:35PM +0100, David Vrabel wrote:
>> On 21/08/15 17:05, Konrad Rzeszutek Wilk wrote:
>>>
>>> I have to concur with that. We can't mandate that ARM 64k page MUST use
>>> indirect descriptors.
>>
>> Then it has to be f
On Thu, Aug 27, 2015 at 9:29 AM, Jan Beulich wrote:
> >>> On 27.08.15 at 17:10, wrote:
> > On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
> >> >>> On 20.07.15 at 16:29, wrote:
> >> > /* Copy bootstrap trampoline to low memory, below 1MB. */
> >> > -mov $sym_ph
Andrew Cooper writes ("Re: [RFC v2 for-4.6 0/2] In-tree feature documentation"):
> On 27/08/15 15:52, Ian Jackson wrote:
> > I do wonder whether cross-referencing all the "issues" is a good idea.
> > It seems like it might be a lot of work to keep them in step.
>
> I don't expect all the issues to
Wei Liu writes ("[PATCH for 4.6] build: fix tarball stubdom build"):
> When we create a source code tarball, mini-os is extracted to
> extras/mini-os directory. When building a source code tarball, we
> shouldn't clone mini-os again.
>
> Only clone mini-os when that directory doesn't exist. This f
Wei Liu writes ("Re: [Xen-devel] [PATCH v2] libxenstore: prefer using the
character device"):
> On Thu, Aug 27, 2015 at 09:04:38AM -0500, Jonathan Creekmore wrote:
> > With the addition of FMODE_ATOMIC_POS in the Linux 3.14 kernel,
> > concurrent blocking file accesses to a single open file descri
On 27/08/15 16:29, Jan Beulich wrote:
On 27.08.15 at 17:10, wrote:
>> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>> On 20.07.15 at 16:29, wrote:
/* Copy bootstrap trampoline to low memory, below 1MB. */
-mov $sym_phys(trampoline_start),%es
Wei Liu writes ("Re: [Xen-devel] [PATCH] build: use correct qemu emulator
binary"):
> On Tue, Aug 25, 2015 at 08:45:07AM -0500, Doug Goldstein wrote:
> > Per http://wiki.qemu.org/ChangeLog/1.0 and the fact that no currently
> > supported distro ships the x86 system emulator binary as 'qemu', this
Wei Liu writes ("Re: [Xen-devel] [DOCS DAY] [PATCH for-4.6 0/5] Cleanup of docs
spread throughout the tree"):
> On Wed, Aug 26, 2015 at 10:09:46AM +0100, Andrew Cooper wrote:
> Whole series:
>
> Acked-by: Wei Liu
Committed-by: Ian Jackson
Thanks,
Ian.
On 27/08/15 18:58, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [RFC v2 for-4.6 0/2] In-tree feature
> documentation"):
>> On 27/08/15 15:52, Ian Jackson wrote:
>>> I do wonder whether cross-referencing all the "issues" is a good idea.
>>> It seems like it might be a lot of work to keep them in
On Thu, Aug 27, 2015 at 04:07:36PM +0200, Roger Pau Monné wrote:
> El 27/08/15 a les 16.01, Jan Beulich ha escrit:
> On 27.08.15 at 13:29, wrote:
> >> When using Intel hardware without shared page tables between the IOMMU
> >> and EPT (I have not tried if the same happens when sharing the pa
1 - 100 of 129 matches
Mail list logo
