On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
> Why does xen_blkfront not enforce kernel device names from domU.cfg?
> In my PV domU.cfg I still have something like this:
> disk=[ 'file:/path,hda,w' ]
>
> With pvops and xen_blkfront I get xvda.
> With xenlinux and xenblk I get hda.
. as it is not implemented on it.
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: Initial botched patch that didn't compile.
v2: Andrew mentioned to "need to set ENOSYS in the xch last
error." - but we do not use 'failwith_xc', and:
a). The error codes you set are no EXX type.
b).
* Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
>
> drivers/firmware/efi/arm-runtime.c
>
> between commit:
>
> 14c43be60166 ("efi/arm*: Drop writable mapping of the UEFI System table")
>
> from the tip tree and commit:
>
> 21c8d
flight 93157 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. This patch
allows the vm_event consumer to specify exactly what MSR-s it is
interested in, and as a side-effect gets rid of the
vmx_introspection_force_enabled_msrs[] special case.
T
On 04/29/16 05:44, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Wednesday, April 27, 2016 3:48 PM
>> +
>> +static void *monitor_bitmap_for_msr(struct domain *d, u32 *msr)
>> +{
>> +ASSERT(d->arch.monitor_msr_bitmap && msr);
>> +
>> +switch ( *msr )
>
> You can always just add a new page to the domain to be used for #VE.
It's there a method to directly assign physical pages to guest from dom0?
Using xc_map_foreign_address just like libvmi?
2016-04-28 23:07 GMT+08:00 Tamas K Lengyel :
>
>
> On Thu, Apr 28, 2016 at 8:36 AM, Big Strong wrote:
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
drivers/firmware/efi/arm-runtime.c
between commit:
14c43be60166 ("efi/arm*: Drop writable mapping of the UEFI System table")
from the tip tree and commit:
21c8dfaa2327 ("Xen: EFI: Parse DT parameters for Xen specifi
On Thu, Apr 28, 2016 at 8:29 PM, Tian, Kevin wrote:
> > From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> > Sent: Thursday, April 28, 2016 4:33 AM
> >
> > Since in-guest debug exceptions are now unconditionally trapped to Xen,
> adding
> > a hook for vm_event subscribers to tap into this new a
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Wednesday, April 27, 2016 3:48 PM
> +
> +static void *monitor_bitmap_for_msr(struct domain *d, u32 *msr)
> +{
> +ASSERT(d->arch.monitor_msr_bitmap && msr);
> +
> +switch ( *msr )
> +{
> +case 0 ... 0x1fff:
> +
On April 29, 2016 10:21 AM, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, April 29, 2016 12:09 AM
> > On April 28, 2016 11:12 PM, Jan Beulich wrote:
> > > >>> On 28.04.16 at 17:03, wrote:
> > > > On April 28, 2016 10:36 PM, Jan Beulich wrote:
> > > >> >>> On 28.04.16 at 16:14, wrote
> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Thursday, April 28, 2016 4:33 AM
>
> Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
> a hook for vm_event subscribers to tap into this new always-on guest event. We
> rename along the way hvm_event_breakpo
> From: Xu, Quan
> Sent: Friday, April 29, 2016 12:09 AM
>
> On April 28, 2016 11:12 PM, Jan Beulich wrote:
> > >>> On 28.04.16 at 17:03, wrote:
> > > On April 28, 2016 10:36 PM, Jan Beulich wrote:
> > >> >>> On 28.04.16 at 16:14, wrote:
> > >> > On April 25, 2016 7:53 PM, Jan Beulich wrote:
On Thu, Apr 28, 2016 at 09:52:14PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 12:23:38AM +0100, Andrew Cooper wrote:
> > On 28/04/2016 19:16, Konrad Rzeszutek Wilk wrote:
> > > diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> > > index 1b67d39..48088ce 100644
> > > ---
flight 93114 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93114/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On Fri, Apr 29, 2016 at 12:23:38AM +0100, Andrew Cooper wrote:
> On 28/04/2016 19:16, Konrad Rzeszutek Wilk wrote:
> > diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> > index 1b67d39..48088ce 100644
> > --- a/xen/common/xsplice.c
> > +++ b/xen/common/xsplice.c
> > @@ -1099,6 +1099,13 @@
On Mon, Apr 25, 2016 at 12:51:44AM -0600, Jan Beulich wrote:
> >>> On 31.03.16 at 10:57, wrote:
> > +#define XRSTOR(pfx) \
> > +if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \
> > +{ \
> > +if ( unlikely(!(ptr->xsave_hdr.xcomp_bv & \
> > +XS
On Mon, Apr 25, 2016 at 01:07:54AM -0600, Jan Beulich wrote:
> Commit 4d27280572 ("x86/xsaves: fix overwriting between non-lazy/lazy
> xsaves") switched to always saving full state when using compacted
> format (which is the only one XSAVES allows). It didn't, however, also
> adjust the restore sid
On 28/04/2016 19:16, Konrad Rzeszutek Wilk wrote:
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> index 1b67d39..48088ce 100644
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -1099,6 +1099,13 @@ static void xsplice_do_action(void)
> data->rc = rc;
> }
>
> +stati
Roger Pau Monné wrote:
> On Thu, Apr 28, 2016 at 09:27:30AM +0100, George Dunlap wrote:
>> On Wed, Apr 27, 2016 at 5:22 PM, Jim Fehlig wrote:
>>> On 04/27/2016 01:38 AM, Roger Pau Monné wrote:
On Tue, Apr 26, 2016 at 10:35:31PM -0600, Jim Fehlig wrote:
> qemu commit 91a097e7 forbids speci
qemu commit 91a097e7 forbids specifying cache mode for empty
drives. Attempting to create a domain with an empty qdisk cdrom
drive results in
qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom,
cache=writeback,id=ide-832: Must specify either driver or file
libxl only allows an e
On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type
> argument to xc_psr_*"):
> > On Tue, Apr 26, 2016 at 04:52:21PM +0200, Roger Pau Monne wrote:
> > > The xc_psr_* functions expect the type to be xc_psr_cat_type
On Thu, Apr 28, 2016 at 02:16:52PM -0400, Konrad Rzeszutek Wilk wrote:
> Currently it is possible to:
>
> 1) xc_xsplice_apply()
> \-> xsplice_action
> spin_lock(payload_lock)
> \- schedule_work()
> spin_unlock(payload_lock);
>
> 2) xc_xsplice_unload()
> \->
flight 93098 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93098/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REGR. vs. 878
flight 92799 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 91479
test-amd64-amd64-libvirt-
On Wed, Apr 27, 2016 at 05:50:56AM +, Jason Long wrote:
> Can it work on Workstation version too? Or just server version of fedora
> needed?
I do it under workstation.
>
>
>
> On Wednesday, April 27, 2016 9:53 AM, Jason Long wrote:
> Not matter.
> I did it too :
>
> # grub2-mkconfig -o
At the 2016 Xen Hackathon I raised the topic of the default xenstored
used. Here are my notes with some new additions and supported
documentation. It would seem we're moving to oxenstored as the default
on Linux distributions and FreeBSD now, if you have issues or concerns
with this please let us k
On Tue, Apr 26, 2016 at 12:48:41PM +0100, Lars Kurth wrote:
> Hi all,
>
> following the recent process to elect new maintainers and committers,
> I would like to suggest the following minor change to our governance
> document. I believe the process we ran recently worked well, so we
> should ch
Currently it is possible to:
1) xc_xsplice_apply()
\-> xsplice_action
spin_lock(payload_lock)
\- schedule_work()
spin_unlock(payload_lock);
2) xc_xsplice_unload()
\-> xsplice_action
spin_lock(payload_lock)
free_payload(data);
s
Wei Liu writes ("Re: [PATCH v3 for-4.7 07/16] libxc: fix usage of uninitialized
variable"):
> Ian, this is a backport candidate.
Noted, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Tue, Apr 26, 2016 at 09:38:45AM -0500, Doug Goldstein wrote:
> When building debug use -Og as the optimization level if its available,
> otherwise retain the use of -O0. -Og has been added by GCC to enable all
> optimizations that to not affect debugging while retaining full
> debugability.
>
>
osstest service owner writes ("[xen-4.3-testing test] 92882: trouble:
blocked/broken/fail/pass"):
> flight 92882 xen-4.3-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/92882/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> incl
Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type
argument to xc_psr_*"):
> On Tue, Apr 26, 2016 at 04:52:21PM +0200, Roger Pau Monne wrote:
> > The xc_psr_* functions expect the type to be xc_psr_cat_type instead of
> > libxl_psr_cbm_type, so do the conversion.
> >
> > Si
On Thu, Apr 28, 2016 at 06:26:09PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH v2 for-4.7 10/14] libxl: add the
> printf-like attributes to a couple of functions"):
> > Sigh. I can't say I like turning that into a macro though. On the other
> > hand there doesn't seem to be
Wei Liu writes ("Re: [Xen-devel] [PATCH v2 for-4.7 10/14] libxl: add the
printf-like attributes to a couple of functions"):
> Sigh. I can't say I like turning that into a macro though. On the other
> hand there doesn't seem to be an elegant way of solving that.
Well, other than suppressing the wa
On Thu, Apr 28, 2016 at 06:19:19PM +0100, Ian Jackson wrote:
> Doug Goldstein writes ("[PATCH v3] tools: detect appropriate debug
> optimization level"):
> > When building debug use -Og as the optimization level if its available,
> > otherwise retain the use of -O0. -Og has been added by GCC to en
Doug Goldstein writes ("[PATCH v3] tools: detect appropriate debug optimization
level"):
> When building debug use -Og as the optimization level if its available,
> otherwise retain the use of -O0. -Og has been added by GCC to enable all
> optimizations that to not affect debugging while retaining
From: "Kyle J. Temkin"
The ARMv8 architecture has a SPSel ("stack pointer selection") machine
register that allows us to determine which exception level's stack
pointer is loaded when an exception occurs. As we don't want to
use the non-priveleged SP_EL0 stack pointer -- or even assume that SP_EL
Wei Liu writes ("Re: [Xen-devel] [PATCH] Fix cpumap setting before passing to
XEN"):
> So what is the conclusion of this discussion so far? I admit I'm a bit
> lost here.
Undoubtedly:
* That "xm ..." generates the reported error is definitely a bug.
* "xm" exists only in versions of Xen now no
flight 93090 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93090/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On Thu, Apr 28, 2016 at 08:52:53AM -0600, Jan Beulich wrote:
> ... as at least certain versions of Windows use such to update the
> MSI-X table. However, to not overly complicate the logic for now
> - only EFLAGS.DF=0 is being handled,
> - only updates not crossing MSI-X table entry boundaries are
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 15:53
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant; Wei Liu
> Subject: [PATCH v2] x86/vMSI-X: also snoop REP MOVS
>
> ... as at least certain versions of Windows use such to update the
> MSI-X ta
On Thu, 28 Apr 2016, Fabio Fantoni wrote:
Il 27/04/2016 20:03, Martin Cerveny ha scritto:
On Wed, 27 Apr 2016, Fabio Fantoni wrote:
Il 27/04/2016 13:26, George Dunlap ha scritto:
On 27/04/16 12:02, Fabio Fantoni wrote:
Hi, I took a look at the new pvusb hotplug code in libxl to try to a
Juergen Gross writes ("Re: [OSSTEST PATCH] crontab: Drop linux-mingo-tip-master
linux-next linux-linus"):
> On 22/04/16 19:08, Roger Pau Monne wrote:
> > This looks fine to me, but I think I needs to be Acked by the Linux
> > maintainers. FWIW:
>
> Acked-by: Juergen Gross
Thanks. I have insta
On 28/04/16 16:49, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 28, 2016 at 11:28:20AM +0100, Wei Liu wrote:
>> On Wed, Apr 27, 2016 at 05:06:27PM +0100, George Dunlap wrote:
>>> Clarify the meaning of nested maintainership.
>>>
>>> Signed-off-by: George Dunlap
>>> ---
>>> We had a discussion about
On April 28, 2016 11:13 PM, Jan Beulich wrote:
> >>> On 25.04.16 at 10:40, wrote:
> > With other patches also in place, still not work.
> > Jianzhong has been left and Quan will take over the task.
>
> May I ask for another try, with current tip of staging plus
> http://lists.xenproject.org/arc
On April 28, 2016 11:12 PM, Jan Beulich wrote:
> >>> On 28.04.16 at 17:03, wrote:
> > On April 28, 2016 10:36 PM, Jan Beulich wrote:
> >> >>> On 28.04.16 at 16:14, wrote:
> >> > On April 25, 2016 7:53 PM, Jan Beulich wrote:
> >> >> >>> On 18.04.16 at 16:00, wrote:
> >> >> > --- a/xen/drivers/
On Thu, Apr 28, 2016 at 11:28:20AM +0100, Wei Liu wrote:
> On Wed, Apr 27, 2016 at 05:06:27PM +0100, George Dunlap wrote:
> > Clarify the meaning of nested maintainership.
> >
> > Signed-off-by: George Dunlap
> > ---
> > We had a discussion about the meaning of nested maintainership at the
> > re
flight 93093 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93093/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Wed, Mar 16, 2016 at 05:22:27AM -0600, Jan Beulich wrote:
> >>> On 15.03.16 at 16:38, wrote:
> > Jan Beulich writes ("Re: [PATCH v2 3/3] xl: new "loglvl" command"):
> >> Yes and no. If all of the sudden the hypervisor didn't have an "error"
> >> log level anymore, what would you do? Mapping "er
On Wed, Apr 27, 2016 at 11:57 PM, Razvan Cojocaru wrote:
> On 04/27/16 23:33, Tamas K Lengyel wrote:
> > Since in-guest debug exceptions are now unconditionally trapped to Xen,
> adding
> > a hook for vm_event subscribers to tap into this new always-on guest
> event. We
> > rename along the way h
>>> On 28.04.16 at 17:03, wrote:
> On April 28, 2016 10:36 PM, Jan Beulich wrote:
>> >>> On 28.04.16 at 16:14, wrote:
>> > On April 25, 2016 7:53 PM, Jan Beulich wrote:
>> >> >>> On 18.04.16 at 16:00, wrote:
>> >> > --- a/xen/drivers/passthrough/vtd/iommu.c
>> >> > +++ b/xen/drivers/passthroug
>>> On 25.04.16 at 10:40, wrote:
> With other patches also in place, still not work.
> Jianzhong has been left and Quan will take over the task.
May I ask for another try, with current tip of staging plus
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg03661.html
?
Thanks, Jan
On Tue, Apr 26, 2016 at 11:54:32AM +0800, Zhenzhong Duan wrote:
> On 2016/4/25 21:26, Ian Jackson wrote:
> >Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Fix cpumap setting
> >before passing to XEN"):
> >>On Wed, Apr 20, 2016 at 03:33:13PM +0100, Wei Liu wrote:
> >>>In principle I think h
On April 28, 2016 10:36 PM, Jan Beulich wrote:
> >>> On 28.04.16 at 16:14, wrote:
> > On April 25, 2016 7:53 PM, Jan Beulich wrote:
> >> >>> On 18.04.16 at 16:00, wrote:
> >> > --- a/xen/drivers/passthrough/vtd/iommu.c
> >> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> >
> >
> >> > -static void
On Thu, Apr 28, 2016 at 8:36 AM, Big Strong wrote:
> I want to set up an EPT page so as to trigger the #VE for testing purpose.
> However, some problems are met.
>
> As the Intel Manual said, there are many conditions to trigger a #VE:
>
> a) If an access to a guest-physical address causes a
... as at least certain versions of Windows use such to update the
MSI-X table. However, to not overly complicate the logic for now
- only EFLAGS.DF=0 is being handled,
- only updates not crossing MSI-X table entry boundaries are handled.
Signed-off-by: Jan Beulich
---
v2: Comment conditional bei
On Thu, Apr 28, 2016 at 4:36 AM, George Dunlap
wrote:
> On 27/04/16 16:48, Tamas K Lengyel wrote:
> > Don't propagate altp2m changes from ept_set_entry for memshare as
> memshare
> > already has the lock. We call altp2m propagate changes once memshare
> > successfully finishes. Allow the hostp2m
>>> On 28.04.16 at 16:14, wrote:
> On April 25, 2016 7:53 PM, Jan Beulich wrote:
>> >>> On 18.04.16 at 16:00, wrote:
>> > --- a/xen/drivers/passthrough/vtd/iommu.c
>> > +++ b/xen/drivers/passthrough/vtd/iommu.c
>
>
>> > -static void iommu_flush_all(void)
>> > +static int iommu_flush_all(void)
I want to set up an EPT page so as to trigger the #VE for testing purpose.
However, some problems are met.
As the Intel Manual said, there are many conditions to trigger a #VE:
a) If an access to a guest-physical address causes an EPT violation, bit
63 (0) of exactly one of the EPT paging-st
Ian Jackson writes ("Re: [RFC PATCH v6 00/28] libxl: Deprivilege qemu"):
> Stefano Stabellini writes ("Re: [RFC PATCH v6 00/28] libxl: Deprivilege
> qemu"):
> > I take that this series is going to miss 4.7 at this stage, right?
>
> I'm afraid so. We concluded that a crucial piece - arranging for
flight 93074 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93074/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REGR. vs. 878
Il 27/04/2016 20:03, Martin Cerveny ha scritto:
On Wed, 27 Apr 2016, Fabio Fantoni wrote:
Il 27/04/2016 13:26, George Dunlap ha scritto:
On 27/04/16 12:02, Fabio Fantoni wrote:
Hi, I took a look at the new pvusb hotplug code in libxl to try to add
also hotplug (with qmp) usbredir tcp channe
On 28/04/16 15:06, Wei Liu wrote:
Hi Julien
Hi Wei,
Can you also CC minios-devel@ in the future for relevant discussions?
Sorry I forgot about this ML. I will do it for the next discussion.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
X
On April 25, 2016 7:53 PM, Jan Beulich wrote:
> >>> On 18.04.16 at 16:00, wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > -static void iommu_flush_all(void)
> > +static int iommu_flush_all(void)
>
> __must_check
>
The iommu_flush_all() i
Hi Julien
Can you also CC minios-devel@ in the future for relevant discussions?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Julien,
Sorry for the late reply.
I have ported the basic framework to make it work. It
can be built and boot, but still in the early stage (lots
of functions are there but empty). The code on my github
(https://github.com/baozich/mini-os) is the latest version
(though there have been a long t
Hello Julien,
Thank you for the advice. I do have a follow up question.
On Thu, Apr 28, 2016 at 2:50 AM, Julien Grall wrote:
> Hello,
>
> On 27/04/16 23:53, Suriyan Ramasami wrote:
>
> How can I check which core is currently active?
>> Judging by this link on big.LITTLE archi
flight 93056 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93056/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
> Xen is not ready for big.LITTLE, so I would highly recommend you to
> disable either all the Cortex-A15 or Cortex-A7.
> For your information, I am planning to send a patch to park any CPUs
> whose MIDR is not matching the boot CPU one.
> Julien Grall
Ok,
I decided to use A15s... How can I
Hello,
On 28/04/16 13:56, Peng Fan wrote:
On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote:
On 28/04/16 07:39, Peng Fan wrote:
Hi Julien,
Hello Peng,
On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote:
Hi Julien,
On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall w
On 4/28/2016 8:39 PM, Jan Beulich wrote:
On 28.04.16 at 14:12, wrote:
I'm still confused why do we need this, especially at such critical
moment. IIUC HVMMEM type is used to get/set mem type, why would someone
define a HVMMEM type but not use it here?
Who knows. And as said - the patch can
On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote:
>
>
>On 28/04/16 07:39, Peng Fan wrote:
>>Hi Julien,
>
>Hello Peng,
>
>>On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote:
>>>Hi Julien,
>>>On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall wrote:
Hello Peng,
On
On 25/04/16 12:18, Stefano Stabellini wrote:
> From: Jan Beulich
>
> For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
> using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
> vcpu_time_info, is calculated from stime_local_stamp using
> gtime_to_gtsc.
>
> However
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 13:31
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel
> Subject: RE: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>
> >>> On 28.04.16 at 13:58, wrote:
> >> -Original Message-
> >> From: Jan
On Thu, Apr 28, 2016 at 06:34:48AM -0600, Jan Beulich wrote:
> >>> On 28.04.16 at 14:06, wrote:
> > On Thu, Apr 28, 2016 at 01:00:57PM +0100, Andrew Cooper wrote:
> >> On 28/04/16 12:59, Wei Liu wrote:
> >> > On Thu, Apr 28, 2016 at 07:40:45PM +0800, Yu, Zhang wrote:
> >> >> Thanks Jan. And I admi
>>> On 28.04.16 at 14:12, wrote:
> I'm still confused why do we need this, especially at such critical
> moment. IIUC HVMMEM type is used to get/set mem type, why would someone
> define a HVMMEM type but not use it here?
Who knows. And as said - the patch can go in as is, I just inquired
because
>>> On 28.04.16 at 14:06, wrote:
> On Thu, Apr 28, 2016 at 01:00:57PM +0100, Andrew Cooper wrote:
>> On 28/04/16 12:59, Wei Liu wrote:
>> > On Thu, Apr 28, 2016 at 07:40:45PM +0800, Yu, Zhang wrote:
>> >> Thanks Jan. And I admire your rigorous thought. :)
>> >>
>> >> On 4/28/2016 6:57 PM, Jan Beul
>>> On 28.04.16 at 13:58, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 April 2016 12:44
>> To: Paul Durrant
>> Cc: Andrew Cooper; xen-devel
>> Subject: RE: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>>
>> >>> On 28.04.16 at 13:17, wrote:
>> >
>>> On 28.04.16 at 14:00, wrote:
>
> On 4/28/2016 7:52 PM, Jan Beulich wrote:
> On 28.04.16 at 13:40, wrote:
>>> On 4/28/2016 6:57 PM, Jan Beulich wrote:
>>> On 28.04.16 at 12:42, wrote:
> That might have been slightly cleaner; but we're going to have to put it
> back as soon a
On 4/28/2016 8:06 PM, Wei Liu wrote:
On Thu, Apr 28, 2016 at 01:00:57PM +0100, Andrew Cooper wrote:
On 28/04/16 12:59, Wei Liu wrote:
On Thu, Apr 28, 2016 at 07:40:45PM +0800, Yu, Zhang wrote:
Thanks Jan. And I admire your rigorous thought. :)
On 4/28/2016 6:57 PM, Jan Beulich wrote:
On 28
On Thu, Apr 28, 2016 at 01:00:57PM +0100, Andrew Cooper wrote:
> On 28/04/16 12:59, Wei Liu wrote:
> > On Thu, Apr 28, 2016 at 07:40:45PM +0800, Yu, Zhang wrote:
> >> Thanks Jan. And I admire your rigorous thought. :)
> >>
> >> On 4/28/2016 6:57 PM, Jan Beulich wrote:
> >> On 28.04.16 at 12:42,
On 28/04/16 12:59, Wei Liu wrote:
> On Thu, Apr 28, 2016 at 07:40:45PM +0800, Yu, Zhang wrote:
>> Thanks Jan. And I admire your rigorous thought. :)
>>
>> On 4/28/2016 6:57 PM, Jan Beulich wrote:
>> On 28.04.16 at 12:42, wrote:
On 28/04/16 11:22, Jan Beulich wrote:
On 28.04.16 at
On 4/28/2016 7:52 PM, Jan Beulich wrote:
On 28.04.16 at 13:40, wrote:
On 4/28/2016 6:57 PM, Jan Beulich wrote:
On 28.04.16 at 12:42, wrote:
That might have been slightly cleaner; but we're going to have to put it
back as soon as the development window opens anyway, so I don't really
see th
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 12:44
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel
> Subject: RE: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>
> >>> On 28.04.16 at 13:17, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.co
On Thu, Apr 28, 2016 at 07:40:45PM +0800, Yu, Zhang wrote:
> Thanks Jan. And I admire your rigorous thought. :)
>
> On 4/28/2016 6:57 PM, Jan Beulich wrote:
> On 28.04.16 at 12:42, wrote:
> >>On 28/04/16 11:22, Jan Beulich wrote:
> >>On 28.04.16 at 10:29, wrote:
> @@ -5529,7 +5527,7
>>> On 28.04.16 at 13:40, wrote:
> On 4/28/2016 6:57 PM, Jan Beulich wrote:
> On 28.04.16 at 12:42, wrote:
>>> That might have been slightly cleaner; but we're going to have to put it
>>> back as soon as the development window opens anyway, so I don't really
>>> see the point of going through
Thanks Jan. And I admire your rigorous thought. :)
On 4/28/2016 6:57 PM, Jan Beulich wrote:
On 28.04.16 at 12:42, wrote:
On 28/04/16 11:22, Jan Beulich wrote:
On 28.04.16 at 10:29, wrote:
@@ -5529,7 +5527,7 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
Jan informed me on IRC that this series is ready to go in (with minor
adjustments). I also went through this series briefly and was satisfied
with it, so:
Release-acked-by: Wei Liu
Feel free to stick that to later versions as well.
Thanks everyone!
Wei.
___
>>> On 28.04.16 at 13:17, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 April 2016 10:50
>> @@ -366,7 +367,22 @@ static int msixtbl_range(struct vcpu *v,
>> ((addr & (PCI_MSIX_ENTRY_SIZE - 1)) ==
>>PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET) &&
>>
>>> On 27.04.16 at 21:27, wrote:
> --- a/xen/arch/x86/test/Makefile
> +++ b/xen/arch/x86/test/Makefile
> @@ -7,15 +7,18 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{
> print "0x"$$2}')
>
> XSPLICE := xen_hello_world.xsplice
> XSPLICE_BYE := xen_bye_world.xsplice
> +XSPLICE_REPL
>>> On 27.04.16 at 21:27, wrote:
> --- a/xen/arch/x86/test/Makefile
> +++ b/xen/arch/x86/test/Makefile
> @@ -6,17 +6,20 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{
> print "0x"$$2}')
> .PHONY: default
>
> XSPLICE := xen_hello_world.xsplice
> +XSPLICE_BYE := xen_bye_world.xspl
>>> On 27.04.16 at 21:27, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/test/Makefile
> @@ -0,0 +1,42 @@
> +include $(XEN_ROOT)/Config.mk
> +
> +CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
> +CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
> +
> -Original Message-
> From: Martin Cerveny [mailto:mar...@c-home.cz]
> Sent: 28 April 2016 12:17
> To: Paul Durrant
> Cc: George Dunlap; Martin Cerveny; xen-de...@lists.xensource.com; Paolo
> Bonzini
> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
>
> Hell
On Wed, Apr 27, 2016 at 06:03:54PM +0100, George Dunlap wrote:
> On 26/04/16 14:44, Wei Liu wrote:
> > Hi all
> >
> > I spent some time this morning to work out the details of xen.git build
> > system.
> >
> > * How build system works at the moment?
> > 1. Stubdom.mk.in and Tools.mk.in define F
>>> On 27.04.16 at 21:27, wrote:
> From: Ross Lagerwall
>
> Add support for loading xsplice payloads. This is somewhat similar to
> the Linux kernel module loader, implementing the following steps:
> - Verify the elf file.
> - Parse the elf file.
> - Allocate a region of memory mapped within a f
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 10:50
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant
> Subject: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>
> ... as at least certain versions of Windows use such to update the
> MSI-X table. How
>>> On 27.04.16 at 21:27, wrote:
> From: Ross Lagerwall
>
> Add Elf routines and data structures in preparation for loading an
> xSplice payload.
>
> We make an assumption that the max number of sections an ELF payload
> can have is 64. We can in future make this be dependent on the
> names of
Hello.
On Thu, 28 Apr 2016, Paul Durrant wrote:
-Original Message-
From: George Dunlap
Sent: 28 April 2016 09:51
To: Martin Cerveny
Cc: xen-de...@lists.xensource.com; Paolo Bonzini; Paul Durrant
Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
(Xen4.6.1)
On Wed, Apr 27
>>> On 27.04.16 at 21:26, wrote:
> The implementation does not actually do any patching.
>
> It just adds the framework for doing the hypercalls,
> keeping track of ELF payloads, and the basic operations:
> - query which payloads exist,
> - query for specific payloads,
> - check*1, apply*1, re
1 - 100 of 165 matches
Mail list logo
