Hi Elena,
On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations
So, taking all of the conversations above into consideration, the
following changes
should be done to this patch:
1. According to Andrew and Jan's suggestions, I'll remove the
CMDLINE_BOOL option,
and deal with CMDLINE without the #ifdef-ary's.
2. Make the option CMDLINE_OVERRIDE depends on E
flight 106532 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106532/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106491
Regressions which
On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
>
> [...]
>
> > I'm currently at ELC and then on vacation so I don't have access to any
> > of the machines currently myself. However the machine I most use to test
> >
On March 07, 2017 12:24 PM, Chao Gao wrote:
>On Tue, Mar 07, 2017 at 02:16:50AM -0700, Jan Beulich wrote:
> On 07.03.17 at 06:52, wrote:
>>> flight 106504 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/106504/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not s
Those assertions as well as mce_[u|d]handlers[], mce_[u|d]handler_num
and mce_action() were intel only and lifted to the common code by c/s
3a91769d6e1. However, MCE handling on AMD does not use mce_[u|d]handlers[]
before and after that commit, so assertions in mce_action() about their
size do not
flight 106529 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106529/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs.
105991
Regressio
On Tue, 7 Mar 2017, Stefano Stabellini wrote:
> > > +
> > > + ring = container_of(work, struct xen_9pfs_dataring, work);
> > > + priv = ring->priv;
> > > +
> > > + while (1) {
> > > + cons = ring->intf->in_cons;
> > > + prod = ring->intf->in_prod;
> > > + rmb();
> >
> >
>
On Tue, 7 Mar 2017, Boris Ostrovsky wrote:
> On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> > Upon receiving a notification from the backend, schedule the
> > p9_xen_response work_struct. p9_xen_response checks if any responses are
> > available, if so, it reads them one by one, calling p9_cli
This run is configured for baseline tests only.
flight 68642 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68642/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-chec
On Tue, 7 Mar 2017, Boris Ostrovsky wrote:
> On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> > Implement struct p9_trans_module create and close functions by looking
> > at the available Xen 9pfs frontend-backend connections. We don't expect
> > many frontend-backend connections, thus walking a
On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
> > +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> > + struct xen_9pfs_dataring *ring)
> > +{
> > + int i;
> > + int ret = -ENOMEM;
> > +
> > + init_w
On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
> > Sync the ring.h file with upstream Xen, to introduce the new ring macros.
> > They will be used by the Xen transport for 9pfs.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: konrad.
On Tue, 7 Mar 2017, Boris Ostrovsky wrote:
> > +static int xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
> > +{
> > + int i, j;
> > +
> > + list_del(&priv->list);
> > +
> > + for (i = 0; i < priv->num_rings; i++) {
> > + if (priv->rings[i].intf == NULL)
> > +
v{,u}comis{s,d} have two operands, so require vex.reg set to ~0.
Spotted by AFL
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_
---
xen/arch/x86/x86_emulate/x86_emulate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 1b507f7..e09975c 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/
flight 106528 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106528/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
106251
Regressio
flight 106536 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106536/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 03/07/2017 07:54 PM, Stefano Stabellini wrote:
> > On Tue, 7 Mar 2017, Julien Grall wrote:
> > Given that upstream GRUB doesn't yet support booting Xen on ARM (without
> > any additional patches), I think that the ability to completely c
flight 106527 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-amd64-xl-qemuu-
flight 106520 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106520/
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. 59254
test-armhf-armhf-xl
Hi Stefano,
On 03/07/2017 07:54 PM, Stefano Stabellini wrote:
On Tue, 7 Mar 2017, Julien Grall wrote:
Given that upstream GRUB doesn't yet support booting Xen on ARM (without
any additional patches), I think that the ability to completely change
the command line from the EFI shell would be usefu
On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Jan,
>
> On 03/07/2017 02:52 PM, Jan Beulich wrote:
> > > > > On 07.03.17 at 15:41, wrote:
> > > Hi Jan,
> > >
> > > On 03/07/2017 02:18 PM, Jan Beulich wrote:
> > > > > > > On 07.03.17 at 14:48, wrote:
> > > > > On 03/07/2017 12:52 PM, Jan Beulich w
On Tue, 7 Mar 2017, Paul Durrant wrote:
> This patch modifies the wrapper functions in xen_common.h to use the
> new xendevicemodel interface if it is available along with compatibility
> code to use the old libxenctrl interface if it is not.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Anthony
On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
L
On 03/07/2017 01:26 PM, Andrew Cooper wrote:
> On 07/03/17 18:18, Boris Ostrovsky wrote:
Don't we need to pass vaddr down to all routines so that they select
appropriate tables? You seem to always be choosing the first one.
>>> IIUC, we clear whole page table subtree covered by one pgd en
flight 106530 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106530/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On Tue, 7 Mar 2017, Roger Pau Monné wrote:
> On Mon, Mar 06, 2017 at 12:00:41PM -0800, Stefano Stabellini wrote:
> > Hi all,
> >
> > This patch series implements a new transport for 9pfs, aimed at Xen
> > systems.
> >
> > The transport is based on a traditional Xen frontend and backend drivers
>
On 07/03/17 18:18, Boris Ostrovsky wrote:
>>> Don't we need to pass vaddr down to all routines so that they select
>>> appropriate tables? You seem to always be choosing the first one.
>> IIUC, we clear whole page table subtree covered by one pgd entry.
>> So, no, there's no need to pass vaddr down
>> Don't we need to pass vaddr down to all routines so that they select
>> appropriate tables? You seem to always be choosing the first one.
> IIUC, we clear whole page table subtree covered by one pgd entry.
> So, no, there's no need to pass vaddr down. Just pointer to page table
> entry is enoug
On Tue, 7 Mar 2017, Géza Gémes wrote:
> Add $DISTRO = "CentOS"
> to the rpm installation targets
> complementing Fedora
>
> Signed-off-by: Géza Gémes
Reviewed-by: Stefano Stabellini
Thanks for the patch!
> lib/common-functions.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
On Tue, 7 Mar 2017, Géza Gémes wrote:
> Signed-off-by: Géza Gémes
Reviewed-by: Stefano Stabellini
I'll commmit
> ---
> lib/commands.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/commands.sh b/lib/commands.sh
> index be445a7..5b653b3 100755
> --- a/lib/comman
Hi Julien,
On 06/02/17 19:16, Julien Grall wrote:
> Hi Andre,
>
> On 30/01/17 18:31, Andre Przywara wrote:
>> To be able to easily send commands to the ITS, create the respective
>> wrapper functions, which take care of the ring buffer.
>> The first two commands we implement provide methods to ma
Hi Jan,
On 03/07/2017 02:52 PM, Jan Beulich wrote:
On 07.03.17 at 15:41, wrote:
Hi Jan,
On 03/07/2017 02:18 PM, Jan Beulich wrote:
On 07.03.17 at 14:48, wrote:
On 03/07/2017 12:52 PM, Jan Beulich wrote:
On 07.03.17 at 12:21, wrote:
2017-03-07 17:36 GMT+08:00 Jan Beulich :
On 07.03.17 a
Hi Stefano,
On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
+static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
+ struct xen_9pfs_dataring *ring)
+{
+ int i;
+ int ret = -ENOMEM;
+
+ init_waitqueue_head(&ring->wq);
+ spin_lock_init(&ring->
SYM_LOCAL_ALIAS_START -- use where there are two local names for one
code
SYM_ALIAS_START -- use where there are two global names for one code
SYM_LOCAL_FUNC_START -- use for local functions
SYM_FUNCTION_START -- use for global functions
SYM_WEAK_FUNC_START -- use for weak functions
SYM_ALIAS_END
Hi Stefano,
On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.c
flight 106515 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106515/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-stop fail REGR. vs. 106491
Regressions which
On 07/03/17 16:43, Jan Beulich wrote:
> Now that all underscore prefixed instances have been replaced, this
> concludes the register renaming project.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists
On 07/03/17 16:42, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/03/17 16:42, Jan Beulich wrote:
> @@ -3266,36 +3266,36 @@ x86_emulate(
> case 0x27: /* daa */
> case 0x2f: /* das */ {
> uint8_t al = _regs.al;
> -unsigned int eflags = _regs._eflags;
> +unsigned int eflags = _regs.eflags;
>
> -_regs._eflags &= ~(X
On Mon, Mar 06, 2017 at 12:00:41PM -0800, Stefano Stabellini wrote:
> Hi all,
>
> This patch series implements a new transport for 9pfs, aimed at Xen
> systems.
>
> The transport is based on a traditional Xen frontend and backend drivers
> pair. This patch series implements the frontend, which ty
Now that all underscore prefixed instances have been replaced, this
concludes the register renaming project.
Signed-off-by: Jan Beulich
--- a/xen/include/public/arch-x86/xen-x86_32.h
+++ b/xen/include/public/arch-x86/xen-x86_32.h
@@ -114,7 +114,7 @@
#elif defined(__XEN__) || defined(__XEN_TOOLS
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -811,7 +811,7 @@ do{ asm volatile (
unsigned long tmp; \
invoke_stub(_PRE_EFLAGS("[efl]", "[msk]", "[tmp]"),
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -146,7 +146,7 @@ int hvm_hypercall(struct cpu_user_regs *
struct vcpu *curr = current;
struct domain *currd = curr->domain;
int mode = hvm_guest_x86_mode(curr);
-unsigned long ea
This is concluding the exercise, perhaps with the exception of seeing
whether some of the auxiliary stuff added to the public header can
now be removed again (which may require tweaking some of the
scripts parsing the headers).
1: x86emul: switch away from temporary 32-bit register names
2: x86/hy
>>> On 07.03.17 at 17:23, wrote:
> The mov to/from cr/dr behave as if they were encoded with Mod = 3. When
> encoded with Mod != 3, no displacement or SIB bytes are fetched.
>
> Add a test with a deliberately malformed ModRM byte. (Also add the
> automatically-generated simd.h to .gitignore.)
>
>>> On 07.03.17 at 15:58, wrote:
> The vlapic code already aborts an APIC assist if an interrupt is deferred
> because a higher priority interrupt has already been delivered (and hence
> its vector is pending in the ISR).
>
> However, it is also necessary to abort an APIC assist in the case where
The mov to/from cr/dr behave as if they were encoded with Mod = 3. When
encoded with Mod != 3, no displacement or SIB bytes are fetched.
Add a test with a deliberately malformed ModRM byte. (Also add the
automatically-generated simd.h to .gitignore.)
Signed-off-by: Andrew Cooper
---
CC: Jan Be
On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> Upon receiving a notification from the backend, schedule the
> p9_xen_response work_struct. p9_xen_response checks if any responses are
> available, if so, it reads them one by one, calling p9_client_cb to send
> them up to the 9p layer (p9_client
Andrew Cooper writes ("[OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner
returning CRASH"):
> ./xtf-runner wants to distinguish between a clean and unclean exits of the
> test. OSSTest doesn't care, so map unclean exit to failure.
Acked-by: Ian Jackson
___
./xtf-runner wants to distinguish between a clean and unclean exits of the
test. OSSTest doesn't care, so map unclean exit to failure.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
ts-xtf-run | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xtf-run b/ts-xtf-run
index
On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> Implement struct p9_trans_module create and close functions by looking
> at the available Xen 9pfs frontend-backend connections. We don't expect
> many frontend-backend connections, thus walking a list is OK.
>
> Send requests to the backend by c
flight 106513 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106513/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106482
test-amd64-i386-xl-qemuu-wi
>
> +static int xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
> +{
> + int i, j;
> +
> + list_del(&priv->list);
> +
> + for (i = 0; i < priv->num_rings; i++) {
> + if (priv->rings[i].intf == NULL)
> + break;
Are we guaranteed that all subseque
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 27 February 2017 14:03
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; George
> Dunlap ; Tim (Xen.org)
> Subject: [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses
The vlapic code already aborts an APIC assist if an interrupt is deferred
because a higher priority interrupt has already been delivered (and hence
its vector is pending in the ISR).
However, it is also necessary to abort an APIC assist in the case where a
higher priority is about to be delivered
>>> On 07.03.17 at 15:41, wrote:
> Hi Jan,
>
> On 03/07/2017 02:18 PM, Jan Beulich wrote:
> On 07.03.17 at 14:48, wrote:
>>> On 03/07/2017 12:52 PM, Jan Beulich wrote:
>>> On 07.03.17 at 12:21, wrote:
> 2017-03-07 17:36 GMT+08:00 Jan Beulich :
> On 07.03.17 at 09:34, wrote:
> Hi Elena,
>
> On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-af
> Hi Elena,
>
> On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-a
Hi Jan,
On 03/07/2017 02:18 PM, Jan Beulich wrote:
On 07.03.17 at 14:48, wrote:
On 03/07/2017 12:52 PM, Jan Beulich wrote:
On 07.03.17 at 12:21, wrote:
2017-03-07 17:36 GMT+08:00 Jan Beulich :
On 07.03.17 at 09:34, wrote:
+static inline char* __init extract_dom0_options(char *cmdline)
+{
On 03/03/17 15:07, Jan Beulich wrote:
> ... and their AVX equivalents.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 03/03/17 15:04, Jan Beulich wrote:
> ... and their AVX equivalents.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 03/03/17 15:07, Jan Beulich wrote:
> ... and its AVX equivalent.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 03/03/17 15:03, Jan Beulich wrote:
> Convert the few existing opcodes so far supported.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 07.03.17 at 14:48, wrote:
> On 03/07/2017 12:52 PM, Jan Beulich wrote:
> On 07.03.17 at 12:21, wrote:
>>> 2017-03-07 17:36 GMT+08:00 Jan Beulich :
>>> On 07.03.17 at 09:34, wrote:
> +static inline char* __init extract_dom0_options(char *cmdline)
> +{
> +char *kextr
On 03/03/17 14:59, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 07.03.17 at 05:24, wrote:
> On Tue, Mar 07, 2017 at 02:16:50AM -0700, Jan Beulich wrote:
> On 07.03.17 at 06:52, wrote:
>>> flight 106504 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/106504/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed
On 03/03/17 14:58, Jan Beulich wrote:
> Previously supported insns are being converted to the new model, and
> several new ones are being added.
>
> To keep the stub handling reasonably simple, integrate SET_SSE_PREFIX()
> into copy_REX_VEX(), at once switching the stubs to use an empty REX
> prefi
Hi Jan,
On 03/07/2017 12:52 PM, Jan Beulich wrote:
On 07.03.17 at 12:21, wrote:
2017-03-07 17:36 GMT+08:00 Jan Beulich :
On 07.03.17 at 09:34, wrote:
+static inline char* __init extract_dom0_options(char *cmdline)
+{
+char *kextra;
+
+if ( (kextra = strstr(cmdline, " -- ")) != NULL
flight 106524 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 105963
Tests which did not succee
On Mon, Mar 06, 2017 at 03:48:24PM -0500, Boris Ostrovsky wrote:
>
> > +static int xen_p4d_walk(struct mm_struct *mm, p4d_t *p4d,
> > + int (*func)(struct mm_struct *mm, struct page *, enum pt_level),
> > + bool last, unsigned long limit)
> > +{
> > + int i, nr, flush = 0;
>
On 27/02/17 14:03, Andrew Cooper wrote:
> The existing pagetable walker has complicated return semantics, which squeeze
> multiple pieces of information into single integer. This would be fine if the
> information didn't overlap, but it does.
>
> Specifically, _PAGE_INVALID_BITS for 3-level guest
>>> On 07.03.17 at 12:21, wrote:
> 2017-03-07 17:36 GMT+08:00 Jan Beulich :
> On 07.03.17 at 09:34, wrote:
>>> +#endif /* CONFIG_CMDLINE_OVERRIDE */
>>> +#endif /* CONFIG_CMDLINE_BOOL */
>>
>> I think this #ifdef-ary can be reduced, along the lines of Andrew's
>> earlier suggestion. But my ma
On Mon, 6 Mar 2017 15:54:17 +0100
Michal Hocko wrote:
> On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
> > On Fri, 3 Mar 2017 09:27:23 +0100
> > Michal Hocko wrote:
> >
> > > On Thu 02-03-17 18:03:15, Igor Mammedov wrote:
> > > > On Thu, 2 Mar 2017 15:28:16 +0100
> > > > Michal Hocko wrote
flight 106511 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-amd64-xl-qemuu-
On 07/03/17 11:26, George Dunlap wrote:
> On 27/02/17 14:03, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Tim Deegan
>> CC: George Dunlap
>> ---
>> xen/arch/x86/mm/shadow/multi.c | 60
>> --
>> 1 file changed, 58
flight 106509 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106509/
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. 59254
test-armhf-armhf-xl
On 27/02/17 14:03, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: George Dunlap
> ---
> xen/arch/x86/mm/shadow/multi.c | 60
> --
> 1 file changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/xe
On Tue, Mar 07, 2017 at 02:16:50AM -0700, Jan Beulich wrote:
On 07.03.17 at 06:52, wrote:
>> flight 106504 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/106504/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which
Thanks for your time reviewing my code.
2017-03-07 17:36 GMT+08:00 Jan Beulich :
On 07.03.17 at 09:34, wrote:
>
> As an initial remark: Am I right in guessing that you manually prefix
> [Xen-devel] to your message subject? Please don't do so - receiving
> patches without that prefix serves a
On 03/03/17 14:56, Jan Beulich wrote:
> This aims at covering most MMX/SSEn/AVX instructions in the 0x0f-escape
> space with memory operands. Not covered here are irregular moves,
> converts, and {,U}COMIS{S,D} (modifying EFLAGS).
>
> Note that the distinction between simd_*_fp isn't strictly neede
This patch creates inline wrapper functions in xen_common.h for all open
coded calls to xc_hvm_XXX() functions outside of xen_common.h so that use
of xen_xc can be made implicit. This again is in preparation for the move
to using libxendevicemodel.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony
This patch modifies the wrapper functions in xen_common.h to use the
new xendevicemodel interface if it is available along with compatibility
code to use the old libxenctrl interface if it is not.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Stefano Stabellini
v4:
- Fix typo
Doing this will make the transition to using the new libxendevicemodel
interface less intrusive on the callers of these functions, since using
the new library will require a change of handle.
NOTE: The patch also moves the 'externs' for xen_xc and xen_fmem from
xen_backend.h to xen_common.h,
This patch is a purely cosmetic change that avoids a name collision in
a subsequent patch.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Paolo Bonzini
Cc: Stefano Stabellini
---
include/exec/ram_addr.h | 4 ++--
include/hw/xen/xen.h| 2 +-
xen-hvm-stub.c | 2 +-
This patch adds code in configure to set CONFIG_XEN_CTRL_INTERFACE_VERSION
to a new value of 490 if libxendevicemodel is present in the build
environment.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Stefano Stabellini
---
configure | 19 +++
1 file changed,
My recent patches to Xen [1] introduced a new library to support
running device models for HVM guests.
This series ports QEMU onto the new library if it is available in the
build environment.
[1] Patches starting with
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=b108240265deea37601f1a60591
On 27/02/17 14:03, Andrew Cooper wrote:
> All actions which refer to the active ldt/gdt/idt or task register
> (e.g. loading a new segment selector) are known as implicit supervisor
> accesses, even when the access originates from user code.
It turns out that this has a bugfix in it which I hadn't
On 27/02/17 14:03, Andrew Cooper wrote:
> All actions which refer to the active ldt/gdt/idt or task register
> (e.g. loading a new segment selector) are known as implicit supervisor
> accesses, even when the access originates from user code.
>
> The distinction is necessary in the pagewalk when SM
flight 68641 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68641/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start fail blocked in 68619
test-amd64-amd
On 3/7/2017 10:52 AM, Reshetova, Elena wrote:
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshet
>>> On 03.03.17 at 15:58, wrote:
> @@ -6183,6 +6579,76 @@ x86_emulate(
> goto cannot_emulate;
> }
>
> +if ( state->simd_size )
> +{
> +#ifdef __XEN__
> +uint8_t *buf = stub.ptr;
> +#else
> +uint8_t *buf = get_stub(stub);
> +#endif
> +
> +generate_exc
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 06 March 2017 19:14
> To: Paul Durrant
> Cc: 'Stefano Stabellini' ; Anthony Perard
> ; xen-de...@lists.xenproject.org; qemu-
> de...@nongnu.org
> Subject: RE: [PATCH v2 5/5] xen: use libxendevicemodel w
>>> On 07.03.17 at 09:34, wrote:
As an initial remark: Am I right in guessing that you manually prefix
[Xen-devel] to your message subject? Please don't do so - receiving
patches without that prefix serves as an indication to the receiver
that (s)he is on the Cc list.
> --- a/xen/arch/arm/setup.
>>> On 07.03.17 at 06:52, wrote:
> flight 106504 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106504/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> [...]
> test-amd64-amd64-xl-qemuu-debianhvm-am
Hi Elena,
On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> sit
On Mon, Mar 06, 2017 at 04:20:58PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
Hi Elena,
On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> sit
1 - 100 of 105 matches
Mail list logo
