On 14/03/17 00:50, Stefano Stabellini wrote:
> Implement functions to handle the xenbus handshake. Upon connection,
> allocate the rings according to the protocol specification.
>
> Initialize a work_struct and a wait_queue. The work_struct will be used
> to schedule work upon receiving an event c
>>> Yi Sun 03/14/17 3:20 AM >>>
>On 17-03-13 06:37:41, Jan Beulich wrote:
>> >>> On 13.03.17 at 03:43, wrote:
>> > On 17-03-10 02:15:20, Jan Beulich wrote:
>> >> >>> On 10.03.17 at 04:21, wrote:
>> >> > On 17-03-08 09:54:04, Jan Beulich wrote:
>> >> >> >>> On 15.02.17 at 09:49, wrote:
>> >> >>
2017-03-13 12:15 keltezéssel, 刘瑞丰 írta:
own@Sylvanas ‹ master › : ~/xen/raisin
[127] % ./raise -y build
[raisin] calling seabios_check_package
[raisin] seabios_check_package done
[raisin] calling ovmf_check_package
[raisin] ovmf_check_package done
[raisin] calling xen_check_package
[raisin] xen_c
>>> Yi Sun 03/14/17 3:42 AM >>>
>There are three scenarios. E.g.
>1. User calls domctl interface on Dom0 to set a COS ID 1 for Dom1 into its
>psr_cos_ids[]. Then, Dom1 is scheduled so that 'psr_ctxt_switch_to()' is
>called which makes COS ID 1 work. For this case, we do not any action.
>
>2. Dom1
On 14/03/17 00:50, Stefano Stabellini wrote:
> Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
> register as a xenbus driver and add struct p9_trans_module to register
> as v9fs driver.
>
> All functions are empty stubs for now.
>
> Signed-off-by: Stefano Stabellini
> Review
On Mon, Mar 13, 2017 at 7:12 PM, Jan Beulich wrote:
On 13.03.17 at 12:43, wrote:
>> --- a/xen/include/asm-arm/mm.h
>> +++ b/xen/include/asm-arm/mm.h
>> @@ -260,6 +260,13 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t
>> *pa, unsigned int flags)
>> #define virt_to_mfn(va) (virt_t
> and ARCH_SPARSEMEM_DEFAULT is enabeld on 64b. So I guess whatever was
> the reason to add this code back in 2006 is not true anymore. So I am
> really wondering. Do we absolutely need to assign pages which are not
> onlined yet to the ZONE_NORMAL unconditionally? Why cannot we put them
> out of a
On 17-03-13 06:35:33, Jan Beulich wrote:
> >>> On 13.03.17 at 03:36, wrote:
> > On 17-03-10 02:09:55, Jan Beulich wrote:
> >> >>> On 10.03.17 at 03:54, wrote:
> >> > On 17-03-08 09:07:10, Jan Beulich wrote:
> >> >> >>> On 15.02.17 at 09:49, wrote:
> >> >> > +ref[old_cos]--;
> >> >> > +sp
flight 106641 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR.
vs. 106574
Regres
On 17-03-13 06:37:41, Jan Beulich wrote:
> >>> On 13.03.17 at 03:43, wrote:
> > On 17-03-10 02:15:20, Jan Beulich wrote:
> >> >>> On 10.03.17 at 04:21, wrote:
> >> > On 17-03-08 09:54:04, Jan Beulich wrote:
> >> >> >>> On 15.02.17 at 09:49, wrote:
> >> >> > @@ -207,6 +233,29 @@ static enum psr_f
Hi Jan,
On 2017/3/13 19:38, Jan Beulich wrote:
On 13.03.17 at 06:12, wrote:
>> I'm confusing about the behavior of HLT instruction in VMX guest mode.
>>
>> I set "hlt exiting" bit to 0 in VMCS, and the vcpu didn't vmexit when execute
>> HLT as expected. However, I used powertop/cpupower on
flight 106638 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106638/
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. 105963
test-amd64-i386-xl-qemuu-
On 13/03/17 21:15, Stefano Stabellini wrote:
> On Mon, 13 Mar 2017, Igor Druzhinin wrote:
>> Saving/restoring the physmap to/from xenstore was introduced to
>> QEMU majorly in order to cover up the VRAM region restore issue.
>> The sequence of restore operations implies that we should know
>> the e
flight 106636 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
It uses the new ring.h macros to declare rings and interfaces.
Signed-off-by: Stefano Stabellini
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
---
hw/9pfs/xen_9pfs.h | 20
1 file changed, 20 insertions(+)
create mode 100644 hw/9pfs/xen_9pfs.h
diff --git a/hw/9pfs/xen_9
Once a request is completed, xen_9pfs_push_and_notify gets called. In
xen_9pfs_push_and_notify, update the indexes (data has already been
copied to the sg by the common code) and send a notification to the
frontend.
Schedule the bottom-half to check if we already have any other requests
pending.
Do not use the ring.h header installed on the system. Instead, import
the header into the QEMU codebase. This avoids problems when QEMU is
built against a Xen version too old to provide all the ring macros.
Signed-off-by: Stefano Stabellini
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
---
NB
Signed-off-by: Stefano Stabellini
Reviewed-by: Greg Kurz
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V
CC: Greg Kurz
---
hw/9pfs/Makefile.objs| 1 +
hw/xen/xen_backend.c | 3 +++
include/hw/xen/xen_backend.h | 3 +++
3 files changed, 7 insertions(+)
di
Write the limits of the backend to xenstore. Connect to the frontend.
Upon connection, allocate the rings according to the protocol
specification.
Initialize a QEMUBH to schedule work upon receiving an event channel
notification from the frontend.
Signed-off-by: Stefano Stabellini
CC: anthony.pe
Implement xen_9pfs_init_in/out_iov_from_pdu and
xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the
data on the ring.
This is safe as we only handle one request per ring at any given time.
Signed-off-by: Stefano Stabellini
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: An
Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
Xen backend and add struct V9fsTransport to register as v9fs transport.
All functions are empty stubs for now.
Signed-off-by: Stefano Stabellini
Reviewed-by: Greg Kurz
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Ane
Upon receiving an event channel notification from the frontend, schedule
the bottom half. From the bottom half, read one request from the ring,
create a pdu and call pdu_submit to handle it.
For now, only handle one request per ring at a time.
Signed-off-by: Stefano Stabellini
CC: anthony.per...
CONFIG_XEN_BACKEND is currently set when the host supports Xen,
regardless of the chosen targets. As a consequence, Xen backends can be
enabled even on targets that don't support Xen.
Fix the issue by setting CONFIG_XEN_BACKEND only for targets that
support Xen.
Signed-off-by: Stefano Stabellini
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 backend, which typically runs in
Dom0. I sent another series to implement the frontend in Linux
(htt
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_cb completes the request). Handle the
ring following the
It uses the new ring.h macros to declare rings and interfaces.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
include/xen/interface/io/9pfs.h | 40
1 file changed, 40 insertions(+)
crea
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 copying each request to one of the
available rings (each fron
Implement functions to handle the xenbus handshake. Upon connection,
allocate the rings according to the protocol specification.
Initialize a work_struct and a wait_queue. The work_struct will be used
to schedule work upon receiving an event channel notification from the
backend. The wait_queue wi
Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
register as a xenbus driver and add struct p9_trans_module to register
as v9fs driver.
All functions are empty stubs for now.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: jgr...@suse.com
CC: Eric Van Hens
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.com
---
NB: The new macros have not been committed to Xen yet. Do
This patch adds a Kconfig option and Makefile support for building the
9pfs Xen driver.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Eric Van Hensbergen
CC: Ron Minnich
CC: Latchesar Ionkov
CC: v9fs-develo...@lists.sourceforge.net
---
net/9p/Kconfig
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 typically runs in
a regular unprivileged guest.
I also sent a series that implement
flight 106637 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106637/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106381
test-amd64-amd64-xl-qemuu-win7-a
On Fri, 10 Mar 2017, Greg Kurz wrote:
> On Thu, 9 Mar 2017 18:54:26 +0100
> Greg Kurz wrote:
>
> > On Mon, 6 Mar 2017 18:12:43 -0800
> > Stefano Stabellini wrote:
> >
> > > Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
> > > Xen backend and add struct V9fsTransport to r
On Thu, 9 Mar 2017, Roger Pau Monné wrote:
> On Tue, Mar 07, 2017 at 10:27:05AM -0800, Stefano Stabellini wrote:
> > 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 n
On Thu, 9 Mar 2017, Boris Ostrovsky 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->lock
On Thu, 9 Mar 2017, Boris Ostrovsky wrote:
> On 03/08/2017 06:58 PM, Stefano Stabellini wrote:
> > Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
> > register as a xenbus driver and add struct p9_trans_module to register
> > as v9fs driver.
> >
> > All functions are empty stub
On Thu, 9 Mar 2017, Gémes Géza wrote:
> Hi,
>
> I've sent my last couple of days on trying to make raisin tests run on
> different distributions. Tried Ubuntu 16.04, Ubuntu 14.04, CentOS 7 and CentOS
> 6.8 so far. The tests fail because of different reasons on these
> distributions:
>
> 1. bussyb
> @@ -2642,6 +2660,38 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
> case VMEXIT_PAUSE:
> svm_vmexit_do_pause(regs);
> break;
> +
> +case VMEXIT_IDTR_READ:
> +hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0,
> VM_EVENT_DESC_IDTR, 0);
> +
On Mon, 13 Mar 2017, Igor Druzhinin wrote:
> Saving/restoring the physmap to/from xenstore was introduced to
> QEMU majorly in order to cover up the VRAM region restore issue.
> The sequence of restore operations implies that we should know
> the effective guest VRAM address *before* we have the VR
flight 106639 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106639/
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
flight 106632 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106632/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail REGR. vs. 106553
test-amd64-i386-xl-q
flight 106635 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106635/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 14 guest-start/debian.repeat fail REGR. vs. 106574
Regressions which
> On 13 Mar 2017, at 16:49, Wei Liu wrote:
>
> On Fri, Mar 03, 2017 at 12:25:05PM +, Roger Pau Monne wrote:
>> From: Ian Jackson
>>
>> This patch adds support for union members which have their own type name.
>>
>> Signed-off-by: Ian Jackson
>
> Reviewed-by: Wei Liu
>
Under the assum
Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortuna
On Mon, Mar 13, 2017 at 11:32 AM, Boris Ostrovsky
wrote:
> There are a couple of problems for Xen PV guests that need to be addressed:
> 1. Xen's set_fixmap op needs non-default handling for
> FIX_GDT_REMAP_BEGIN range
> 2. GDT remapping for PV guests needs to be RO for both 64 and 32-bit guests.
On 03/09/2017 06:17 PM, Boris Ostrovsky wrote:
> On 03/09/2017 05:31 PM, Thomas Garnier wrote:
>> On Thu, Mar 9, 2017 at 2:13 PM, Boris Ostrovsky
>> wrote:
> I don't have any experience with Xen so it would be great if virtme can
> test it.
I am pretty sure I tested this series at so
On 13/03/17 15:45, Jan Beulich wrote:
On 06.03.17 at 17:42, wrote:
>> +struct mapping_info
>> +{
>> +unsigned int level, order;
>> +void *va;
>> +intpte_t *pte, *fe_pte;
> Having got quite a bit into the patch, I think I've finally understood that
> "fe" here is meant to match up
On Mon, Mar 13, 2017 at 10:32 AM, Boris Ostrovsky
wrote:
> No, it will need a few small changes. I am actually finishing the test
> run (in the next hour or so) and will reply on the Linux thread.
>
Great, thanks again!
--
Thomas
___
Xen-devel mail
On 03/13/2017 01:30 PM, Thomas Garnier wrote:
> On Mon, Mar 13, 2017 at 6:09 AM, Boris Ostrovsky
> wrote:
>> On 03/11/2017 08:06 AM, Andrew Cooper wrote:
>>> On 11/03/2017 03:58, Boris Ostrovsky wrote:
On 03/10/2017 09:39 PM, Boris Ostrovsky wrote:
> I am looking into GDT remap series [0]
On Mon, Mar 13, 2017 at 6:09 AM, Boris Ostrovsky
wrote:
> On 03/11/2017 08:06 AM, Andrew Cooper wrote:
>> On 11/03/2017 03:58, Boris Ostrovsky wrote:
>>> On 03/10/2017 09:39 PM, Boris Ostrovsky wrote:
I am looking into GDT remap series [0] which crashes PV guests and it
seems that the pr
On Mon, Mar 13, 2017 at 6:29 AM, Razvan Cojocaru
wrote:
> On 03/13/2017 02:19 PM, Jan Beulich wrote:
> On 13.03.17 at 13:01, wrote:
>>> On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
wrote:
> On 10/03/17 07:34, Jan Beulich wrote:
>
flight 106634 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106634/
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. 105963
test-amd64-i386-xl-qemuu-
On Wed, Mar 08, 2017 at 03:49:30PM +0100, Juergen Gross wrote:
> Commit 78fb69ad9 ("tools/Rules.mk: Properly handle libraries with
> recursive dependencies.") introduced a copy and paste error in
> tools/Rules.mk:
>
> LDLIBS_libxenstore and SHLIB_libxenstore don't use SHDEPS_libxenstore
> but SHDE
On Fri, Mar 03, 2017 at 12:25:05PM +, Roger Pau Monne wrote:
> From: Ian Jackson
>
> This patch adds support for union members which have their own type name.
>
> Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-de
On Fri, Mar 03, 2017 at 12:25:06PM +, Roger Pau Monne wrote:
> This removal applies to both the hypervisor and the toolstack side of PVHv1.
>
> Note that on the toolstack side a new PVH domain type is introduced to libxl.
> The "none" device model version is removed, together with the "pvh" fi
>>> On 06.03.17 at 17:42, wrote:
> +struct mapping_info
> +{
> +unsigned int level, order;
> +void *va;
> +intpte_t *pte, *fe_pte;
Having got quite a bit into the patch, I think I've finally understood that
"fe" here is meant to match up with "fep" - a comment might be helpful.
> +bo
>2017-03-13 19:52 GMT+08:00 Jan Beulich :
@@ -1566,14 +1557,14 @@ void __init noreturn __start_xen(unsigned long
mbi_p)
/* Grab the DOM0 command line. */
cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
-if ( (cmdline != NULL) || (kextra !
flight 106630 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106630/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
Let's add Andi
On Fri 10-03-17 16:53:33, Michal Hocko wrote:
> On Fri 10-03-17 14:58:07, Michal Hocko wrote:
> [...]
> > This would explain why onlining from the last block actually works but
> > to me this sounds like a completely crappy behavior. All we need to
> > guarantee AFAICS is that Norma
Michal Hocko writes:
> On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote:
>> >
>> > What is the API those guests ask for the memory? And who is actually
>> > responsible to ask for that memory? Is it a kernel or userspace
>> > solution?
>>
>> Whatever, this can even be a system administrator runn
On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote:
I agree with your general sentiment that this stuff is very
nonintuitive.
My criterion for nonintuitive is probably different because I would
call this _completely_unusable_. Sorry for being so loud about this but
the more I look i
On Mon 13-03-17 14:57:12, Igor Mammedov wrote:
> On Mon, 13 Mar 2017 11:43:02 +0100
> Michal Hocko wrote:
>
> > On Mon 13-03-17 11:31:10, Igor Mammedov wrote:
> > > On Fri, 10 Mar 2017 14:58:07 +0100
> > [...]
> > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> > > > [
On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote:
> Michal Hocko writes:
>
> > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> >> Michal Hocko writes:
> >>
> >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> >> >> > >
> >> >> > >- suggested RFC is not acceptable from virt point
On 13/03/17 11:05, Jan Beulich wrote:
> When an FPU instruction with a memory destination fails during the
> memory write, it should not affect FPU register state. Due to the way
> we emulate FPU (and SIMD) instructions, we can only guarantee this by
> - backing out changes to the FPU register stat
On Mon, 13 Mar 2017 11:43:02 +0100
Michal Hocko wrote:
> On Mon 13-03-17 11:31:10, Igor Mammedov wrote:
> > On Fri, 10 Mar 2017 14:58:07 +0100
> [...]
> > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0x3f
>>> On 13.03.17 at 12:43, wrote:
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -260,6 +260,13 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t
> *pa, unsigned int flags)
> #define virt_to_mfn(va) (virt_to_maddr(va) >> PAGE_SHIFT)
> #define mfn_to_virt(mfn) (ma
Michal Hocko writes:
> On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
>> Michal Hocko writes:
>>
>> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
>> >> > >
>> >> > >- suggested RFC is not acceptable from virt point of view
>> >> > > as it regresses guests on top of x86 k
>>> On 13.03.17 at 14:24, wrote:
> On 13/03/17 13:05, Jan Beulich wrote:
> On 13.03.17 at 13:51, wrote:
>>> On 13/03/17 12:03, Jan Beulich wrote:
>>> On 10.03.17 at 17:27, wrote:
> @@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void)
> cpuid_leaf(i, &p->bas
On 13/03/17 13:05, Jan Beulich wrote:
On 13.03.17 at 13:51, wrote:
>> On 13/03/17 12:03, Jan Beulich wrote:
>> On 10.03.17 at 17:27, wrote:
@@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void)
cpuid_leaf(i, &p->basic.raw[i]);
}
+
On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> Michal Hocko writes:
>
> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> >> > >
> >> > >- suggested RFC is not acceptable from virt point of view
> >> > > as it regresses guests on top of x86 kvm/vmware which
> >> > >
On 03/11/2017 08:06 AM, Andrew Cooper wrote:
> On 11/03/2017 03:58, Boris Ostrovsky wrote:
>> On 03/10/2017 09:39 PM, Boris Ostrovsky wrote:
>>> I am looking into GDT remap series [0] which crashes PV guests and it
>>> seems that the problem lies in the fact that we cannot establish new
>>> mapping
>>> On 13.03.17 at 13:51, wrote:
> On 13/03/17 12:03, Jan Beulich wrote:
> On 10.03.17 at 17:27, wrote:
>>> @@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void)
>>> cpuid_leaf(i, &p->basic.raw[i]);
>>> }
>>>
>>> +if ( p->basic.max_leaf >= 4 )
>>> +{
>>> +
Boris Ostrovsky writes:
> On 03/02/2017 12:53 PM, Vitaly Kuznetsov wrote:
>> Changes since v1:
>> - Patches 1,2 and 3 were split and reordered to avoid adding temporary
>>#ifdefs [Juergen Gross]
>> - Juergen's R-b added to what is now patches 14 and 15 (patches 4 and 5
>>in v1). Due to re
Michal Hocko writes:
> On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
>> > >
>> > >- suggested RFC is not acceptable from virt point of view
>> > > as it regresses guests on top of x86 kvm/vmware which
>> > > both use ACPI based memory hotplug.
>> > >
>> > >- u
On 13/03/17 12:03, Jan Beulich wrote:
On 10.03.17 at 17:27, wrote:
>> Leaf 0x4 is reserved by AMD. For Intel, it is a multi-invocation leaf with
>> ecx enumerating different cache details.
>>
>> Add a new union for it in struct cpuid_policy, collect it from hardware in
>> calculate_raw_polic
On 03/13/2017 02:40 PM, Jan Beulich wrote:
On 13.03.17 at 13:29, wrote:
>> On 03/13/2017 02:19 PM, Jan Beulich wrote:
>>> I think as long as there's no need for the guest to use an operation
>>> on itself, it should not be a hvmop. After all, if you make it a domctl
>>> now and later find a n
>>> On 13.03.17 at 13:29, wrote:
> On 03/13/2017 02:19 PM, Jan Beulich wrote:
>> I think as long as there's no need for the guest to use an operation
>> on itself, it should not be a hvmop. After all, if you make it a domctl
>> now and later find a need for it to be called by the guest, we can
>>
>>> On 13.03.17 at 03:43, wrote:
> On 17-03-10 02:15:20, Jan Beulich wrote:
>> >>> On 10.03.17 at 04:21, wrote:
>> > On 17-03-08 09:54:04, Jan Beulich wrote:
>> >> >>> On 15.02.17 at 09:49, wrote:
>> >> > @@ -207,6 +233,29 @@ static enum psr_feat_type
> psr_cbm_type_to_feat_type(enum cbm_type t
>>> On 13.03.17 at 03:36, wrote:
> On 17-03-10 02:09:55, Jan Beulich wrote:
>> >>> On 10.03.17 at 03:54, wrote:
>> > On 17-03-08 09:07:10, Jan Beulich wrote:
>> >> >>> On 15.02.17 at 09:49, wrote:
>> >> > +ref[old_cos]--;
>> >> > +spin_unlock(&info->ref_lock);
>> >> > +
>> >> > +/*
>
>>> On 13.03.17 at 12:55, wrote:
> On 13/03/17 11:03, Jan Beulich wrote:
>> @@ -1006,22 +1007,31 @@ do {
>> rc = _get_fpu(_type, _fic, ctxt, ops); \
>> if ( rc ) goto done;\
>> } while (0)
>> -#define _put_fpu()
On 03/13/2017 02:19 PM, Jan Beulich wrote:
On 13.03.17 at 13:01, wrote:
>> On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
>>> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
>>> wrote:
On 10/03/17 07:34, Jan Beulich wrote:
On 09.03.17 at 18:29, wrote:
>> On Thu, Mar 9, 2017
On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> On Thu, 9 Mar 2017 13:54:00 +0100
> Michal Hocko wrote:
>
> [...]
> > > It's major regression if you remove auto online in kernels that
> > > run on top of x86 kvm/vmware hypervisors, making API cleanups
> > > while breaking useful functionality do
>>> On 13.03.17 at 13:01, wrote:
> On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
>> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
>> wrote:
>>> On 10/03/17 07:34, Jan Beulich wrote:
>>> On 09.03.17 at 18:29, wrote:
> On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich wrote:
>> However -
>>> On 10.03.17 at 17:44, wrote:
> @@ -938,6 +927,21 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> }
> break;
>
> +case 0xb:
> +/*
> + * In principle, this leaf is Intel-only. In practice, it is tightly
> + * coupled with x2apic, and we
>>> On 10.03.17 at 17:32, wrote:
> The thermal/performance leaf was previously hidden from HVM guests, but fully
> visible to PV guests. Most of the leaf refers to MSR availability, and there
> is nothing an unprivileged PV guest can do with the information, so hide the
> leaf entirely.
>
> Sign
>>> On 10.03.17 at 17:27, wrote:
> Leaf 0x4 is reserved by AMD. For Intel, it is a multi-invocation leaf with
> ecx enumerating different cache details.
>
> Add a new union for it in struct cpuid_policy, collect it from hardware in
> calculate_raw_policy(), audit it in recalculate_cpuid_policy()
On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
> wrote:
>> On 10/03/17 07:34, Jan Beulich wrote:
>> On 09.03.17 at 18:29, wrote:
On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich wrote:
> However - is this interface supposed to be usable by
On 13/03/17 11:03, Jan Beulich wrote:
> ..., splitting parts of it into check_*() macros. This is in
> preparation of making ->put_fpu() do further adjustments to register
> state. (Some of the check_xmm() invocations could be avoided, as in
> some of the cases no insns handled there can actually r
>>> On 10.03.17 at 18:36, wrote:
> 2017-03-10 23:03 GMT+08:00 Jan Beulich :
> On 09.03.17 at 04:13, wrote:
>>> If CMDLINE is set, the cmdline_parse() routine will append the bootloader
>>> command line to this string, forming the complete command line
>>> before parsing.
>>
>> I disagree to m
>>> On 10.03.17 at 18:10, wrote:
> On 28/02/17 09:31, Jan Beulich wrote:
> On 27.02.17 at 16:10, wrote:
>>> On 22/02/17 10:10, Jan Beulich wrote:
>>> On 22.02.17 at 11:00, wrote:
> On 22/02/17 09:23, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> The domain builde
flight 106627 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106627/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 16 guest-start.2fail pass in 106605
Regressions which are regarded a
>>> On 13.03.17 at 12:22, wrote:
> On 13/03/17 10:59, Jan Beulich wrote:
> On 13.03.17 at 11:29, wrote:
>>> On 13/03/17 09:24, Jan Beulich wrote:
>>> On 10.03.17 at 18:22, wrote:
> On 08.03.2017 13:54, Jan Beulich wrote:
>> All,
>>
>> I am pleased to announce the release
From: Vijaya Kumar K
On ARM, virt_to_mfn uses the hardware for address
translation. So if the virtual address is not mapped translation
fault is raised.On ARM, DIRECTMAP_VIRT region is direct mapped.
On ARM with NUMA, While initializing second memory node,
panic is triggered from init_node_heap(
>>> On 13.03.17 at 06:12, wrote:
> I'm confusing about the behavior of HLT instruction in VMX guest mode.
>
> I set "hlt exiting" bit to 0 in VMCS, and the vcpu didn't vmexit when execute
> HLT as expected. However, I used powertop/cpupower on host to watch the pcpu's
> c-states, it seems that th
>>> On 11.03.17 at 09:42, wrote:
> On 3/11/2017 12:59 AM, Andrew Cooper wrote:
>> On 08/03/17 15:33, Yu Zhang wrote:
>>> --- a/xen/arch/x86/hvm/dm.c
>>> +++ b/xen/arch/x86/hvm/dm.c
>>> @@ -288,6 +288,7 @@ static int inject_event(struct domain *d,
>>> return 0;
>>> }
>>>
>>> +#define DMO
On 13/03/17 11:03, Jan Beulich wrote:
> Move "cannot_emulate" and make it go through the common (error) exit
> path.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen
>>> On 11.03.17 at 09:42, wrote:
> On 3/11/2017 12:17 AM, Jan Beulich wrote:
> On 08.03.17 at 16:33, wrote:
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -611,6 +611,11 @@ void p2m_change_type_range(struct domain *d,
>>> int p2m_change_type_one(struct domain
>>> On 11.03.17 at 09:42, wrote:
> On 3/11/2017 12:03 AM, Jan Beulich wrote:
>> But there's a wider understanding issue I'm having here: What is
>> an "entry" here? Commonly I would assume this to refer to an
>> individual (4k) page, but it looks like you really mean table entry,
>> i.e. possibly
On 13/03/17 10:59, Jan Beulich wrote:
On 13.03.17 at 11:29, wrote:
>> On 13/03/17 09:24, Jan Beulich wrote:
>> On 10.03.17 at 18:22, wrote:
On 08.03.2017 13:54, Jan Beulich wrote:
> All,
>
> I am pleased to announce the release of Xen 4.6.5. This is
> available immed
1 - 100 of 163 matches
Mail list logo
