Re: [Xen-devel] [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy
When you say "not tools", I take it to mean that you're not exposing that option through the libxl interface? Yes. tools/libxc/xc_domain.c:xc_assign_dt_device() most certainly does pass it in, and that's the level I'm talking about. Someone reviewing this patch series needs to know, when xc or libxl set NO_RDM, what will be the effect? The fact that libxc *shouldn't* set NO_RDM for PCI devices doesn't mean it won't happen. Now looking at the end of the series and grepping for "XEN_DOMCTL_DEV.*RDM", these values are *read and acted on* in exactly two places: xen/arch/x86/mm/p2m.c: The whole point of this series; if the p2m is occupied already, and flag == RDM_STRICT, return an error; otherwise ignore it. xen/drivers/passthrough/device_tree.c: If flag != NO_RDM, return an error. So the meaning of the flags is: For pci devices: - RDM_RELAXED, NO_RDM: ignore conflicts in set_identity_p2m_entry() - RDM_STRICT: error on conflicts in set_identity_p2m_entry() for dt devices: - Error if not NO_RDM Correct. It doesn't look to me like the NO_RDM setting actually adds any semantic meaning. What I see in the list of references you gave is a request from the list below is Julien saying this: "I would also add a XEN_DOMCTL_DEV_NO_RDM that would be use for non-PCI assignment." It looks a bit like what you did is said, "Well Julien asked for a NO_RDM setting, so here's a NO_RDM setting." Which while perhaps understandable, doesn't make the value have any more usefulness. It seems to me that the real problem is that you had two values to begin with, rather than actually having flags (as the name would imply). This what I would suggest. Make a single flag: #define _XEN_DOMCTL_DEV_RDM_RELAXED 0 #define XEN_DOMCTL_DEV_RDM_RELAXED (1U<<_XEN_DOMCTL_DEV_RDM_RELAXED) Then make the meaning of the flags as follows: * for pci devices: - RDM_RELAXED flag SET: ignore conflicts in set_identity_p2m_entry() - RDM_RELAXED flag CLEAR: error on conflicts in set_identity_p2m_entry() No problem. * for dt devices: - Ignore this flag entirely But we still a flag to assign_device() like this, diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c index 5d3842a..a182487 100644 --- a/xen/drivers/passthrough/device_tree.c +++ b/xen/drivers/passthrough/device_tree.c @@ -52,7 +52,8 @@ int iommu_assign_dt_device(struct domain *d, struct dt_device_node *dev) goto fail; } -rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev)); +rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev), + XEN_DOMCTL_DEV_RDM_RELAXED); if ( rc ) goto fail; Or rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev), 0)? Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 59019: regressions - FAIL
flight 59019 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/59019/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 3b91e44996ea6ae1276bce1cc44f38701c53ee6f baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee Ian Jackson Martin Lucina Wei Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 535 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 59010: tolerable FAIL - PUSHED
flight 59010 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/59010/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 11 guest-start fail like 58973 test-amd64-i386-libvirt 11 guest-start fail like 58973 test-amd64-amd64-libvirt 11 guest-start fail like 58973 test-armhf-armhf-xl-rtds 11 guest-start fail like 58973 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: qemuud2966f804d70a244f5dde395fc5d22a50ed3e74e baseline version: qemuu2b464e13f0d30e6c0b8f69ec908fceab30aea986 People who touched revisions under test: Laurent Vivier Peter Maydell jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt pass test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu
Re: [Xen-devel] [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy
I don't happen to think these "override" semantics are actually going to turn out to be that useful; I do think a "default" semantic would be useful. But I'd be content if the name of the current setting were switched to "override" to make the semantics more clear. We can always add in "default" at some later point if we really want. Just as I said you'd better ping Jan or Kevin to make a point. I just have a talk with Kevin, and he think this is fine to him but I'm still not sure what's Jan's idea. Anyway, this shouldn't a big deal to change code so just let me follow yours right now. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling
> -Original Message- > From: Wu, Feng > Sent: Thursday, July 02, 2015 12:33 PM > To: Dario Faggioli > Cc: xen-devel; k...@xen.org; jbeul...@suse.com; andrew.coop...@citrix.com; > Tian, Kevin; Zhang, Yang Z; george.dun...@eu.citrix.com; Wu, Feng > Subject: RE: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU > scheduling > > > > > -Original Message- > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > > Sent: Tuesday, June 30, 2015 10:58 AM > > To: Wu, Feng > > Cc: xen-devel; k...@xen.org; jbeul...@suse.com; > andrew.coop...@citrix.com; > > Tian, Kevin; Zhang, Yang Z; george.dun...@eu.citrix.com; Wu, Feng > > Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during > vCPU > > scheduling > > > > On Mon, 2015-06-29 at 18:36 +0100, Andrew Cooper wrote: > > > > > > > > The basic idea here is: > > > 1. When vCPU's state is RUNSTATE_running, > > > - set 'NV' to 'Notification Vector'. > > > - Clear 'SN' to accpet PI. > > > - set 'NDST' to the right pCPU. > > > 2. When vCPU's state is RUNSTATE_blocked, > > > - set 'NV' to 'Wake-up Vector', so we can wake up the > > > related vCPU when posted-interrupt happens for it. > > > - Clear 'SN' to accpet PI. > > > 3. When vCPU's state is RUNSTATE_runnable/RUNSTATE_offline, > > > - Set 'SN' to suppress non-urgent interrupts. > > > (Current, we only support non-urgent interrupts) > > > - Set 'NV' back to 'Notification Vector' if needed. > > > > > It might be me, but it feels a bit odd to see RUNSTATE-s being (ab)used > > directly for this, as it does feel odd to see arch specific code being > > added in there. > > > > Can't this be done in context_switch(), which is already architecture > > specific? I was thinking to something very similar to what has been done > > for PSR, i.e., on x86, put everything in __context_switch(). > > > > Looking at who's prev and who's next, and at what pause_flags each has > > set, you should be able to implement all of the above logic. > > > > Or am I missing something? > > As mentioned in the description of this patch, here we need to do > something when the vCPU's state is changed, can we get the > state transition in __context_switch(), such as "running -> blocking"? > > Thanks, > Feng And ' vcpu_runstate_change ' is a central place where the vCPU's state gets changed. Thanks, Feng > > > > > Regards, > > Dario > > > > -- > > <> (Raistlin Majere) > > - > > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling
> -Original Message- > From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > Sent: Tuesday, June 30, 2015 10:58 AM > To: Wu, Feng > Cc: xen-devel; k...@xen.org; jbeul...@suse.com; andrew.coop...@citrix.com; > Tian, Kevin; Zhang, Yang Z; george.dun...@eu.citrix.com; Wu, Feng > Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU > scheduling > > On Mon, 2015-06-29 at 18:36 +0100, Andrew Cooper wrote: > > > > > The basic idea here is: > > 1. When vCPU's state is RUNSTATE_running, > > - set 'NV' to 'Notification Vector'. > > - Clear 'SN' to accpet PI. > > - set 'NDST' to the right pCPU. > > 2. When vCPU's state is RUNSTATE_blocked, > > - set 'NV' to 'Wake-up Vector', so we can wake up the > > related vCPU when posted-interrupt happens for it. > > - Clear 'SN' to accpet PI. > > 3. When vCPU's state is RUNSTATE_runnable/RUNSTATE_offline, > > - Set 'SN' to suppress non-urgent interrupts. > > (Current, we only support non-urgent interrupts) > > - Set 'NV' back to 'Notification Vector' if needed. > > > It might be me, but it feels a bit odd to see RUNSTATE-s being (ab)used > directly for this, as it does feel odd to see arch specific code being > added in there. > > Can't this be done in context_switch(), which is already architecture > specific? I was thinking to something very similar to what has been done > for PSR, i.e., on x86, put everything in __context_switch(). > > Looking at who's prev and who's next, and at what pause_flags each has > set, you should be able to implement all of the above logic. > > Or am I missing something? As mentioned in the description of this patch, here we need to do something when the vCPU's state is changed, can we get the state transition in __context_switch(), such as "running -> blocking"? Thanks, Feng > > Regards, > Dario > > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 58974: regressions - FAIL
Hi Dario, 2015-06-30 10:14 GMT-07:00 Dario Faggioli : > Hey Meng, > > you wanted to "get in touch" with OSSTest failures for RTDS, didn't you? > Well, Here you go! :-P > Yes. Thank you very much for cc. me and the very useful explanation of how to read the log! > [I'm adding IanC and Julien, as this is ARM related] > > On Tue, 2015-06-30 at 05:18 +, osstest service user wrote: >> flight 58974 xen-unstable real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/58974/ >> > So, have a look at the link above, and search 'rtds' in the webpage. > > You'll see that test is passing on x86: > http://logs.test-lab.xenproject.org/osstest/logs/58974/test-amd64-amd64-xl-rtds/info.html > > But it's failing on ARM: > http://logs.test-lab.xenproject.org/osstest/logs/58974/test-armhf-armhf-xl-rtds/info.html > > As it's said here as well: >> Tests which did not succeed, but are not blocking: >> test-amd64-amd64-xl-pvh-intel 11 guest-start fail never >> pass >> test-amd64-amd64-xl-pvh-amd 11 guest-start fail never >> pass >> test-armhf-armhf-xl-rtds 11 guest-start fail never >> pass > > It is, apparently, constantly and consistently failing on ARM, as shown > by the history of the job, on the xen-unstable branch: > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl-rtds/xen-unstable > > To actually see what happens, check the details of the job, and the > content of the various captured logs and files. > > For instance, here's the serial console output: > http://logs.test-lab.xenproject.org/osstest/logs/58974/test-armhf-armhf-xl-rtds/serial-arndale-bluewater.log > > Go to the bottom of it, you'll find the splat. Yes. I saw it. :-) > > Hope this has been helpful... This is very helpful! > if you'd b able to have a look at what's > happening, that would be awesome. If you don't have time, I will have a > look myself, but only in a few days. > Hmm, this is another bug for RTDS on ARM. :-( I don't have an ARM board set up right now. I'm not sure if I can run/test it on ARM. I'm curious if this bug is similar with the previous lock-related bug of RTDS scheduler on ARM. Denys fixed the previous bug at http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg03933.html Best Regards, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, July 01, 2015 9:26 PM
> To: Andrew Cooper
> Cc: Wu, Feng; xen-devel@lists.xen.org; Zhang, Yang Z;
> george.dun...@eu.citrix.com; Tian, Kevin; k...@xen.org; jbeul...@suse.com
> Subject: Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU
> is blocked
>
> On Tue, 2015-06-30 at 11:11 +0100, Andrew Cooper wrote:
> > On 24/06/15 06:18, Feng Wu wrote:
>
> > > +/*
> > > + * Handle VT-d posted-interrupt when VCPU is blocked.
> > > + */
> > > +static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
> > > +{
> > > +struct arch_vmx_struct *vmx;
> > > +unsigned int cpu = smp_processor_id();
> > > +
> > > +spin_lock(&per_cpu(pi_blocked_vcpu_lock, cpu));
> > > +
> > > +/*
> > > + * FIXME: The length of the list depends on how many
> > > + * vCPU is current blocked on this specific pCPU.
> > > + * This may hurt the interrupt latency if the list
> > > + * grows to too many entries.
> > > + */
> > > +list_for_each_entry(vmx, &per_cpu(pi_blocked_vcpu, cpu),
> > > +pi_blocked_vcpu_list)
> > > +if ( vmx->pi_desc.on )
> > > +tasklet_schedule(&vmx->pi_vcpu_wakeup_tasklet);
> >
> > There is a logical bug here. If we have two NV's delivered to this
> > pcpu, we will kick the first vcpu twice.
> >
> > On finding desc.on, a kick should be scheduled, then the vcpu removed
> > from this list. With desc.on set, we know for certain that another NV
> > will not arrive for it until it has been scheduled again and the
> > interrupt posted.
> >
> Yes, that seems a possible issue (and one that should indeed be
> avoided).
>
> I'm still unsure about the one that I raised myself but, if it is
> possible to have more than one vcpu in a pcpu list, with desc.on==true,
> then it looks to me that we kick all of them, for each notification.
>
> Added what Andrew's spotted, if there are a bunch of vcpus, queued with
> desc.on==ture, and a bunch of notifications arrives before the tasklet
> gets executed, we'll be kicking the whole bunch of them for a bunch of
> times! :-/
As Andrew mentioned, removing the vCPUs with desc.on = true from the
list can avoid kick vCPUs for multiple times.
Thanks,
Feng
>
> Regards,
> Dario
>
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, June 30, 2015 6:12 PM
> To: Wu, Feng; xen-devel@lists.xen.org
> Cc: k...@xen.org; jbeul...@suse.com; Tian, Kevin; Zhang, Yang Z;
> george.dun...@eu.citrix.com
> Subject: Re: [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
>
> On 24/06/15 06:18, Feng Wu wrote:
> > @@ -1848,6 +1869,33 @@ static struct hvm_function_table __initdata
> vmx_function_table = {
> > .enable_msr_exit_interception = vmx_enable_msr_exit_interception,
> > };
> >
> > +/*
> > + * Handle VT-d posted-interrupt when VCPU is blocked.
> > + */
> > +static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
> > +{
> > +struct arch_vmx_struct *vmx;
> > +unsigned int cpu = smp_processor_id();
> > +
> > +spin_lock(&per_cpu(pi_blocked_vcpu_lock, cpu));
> > +
> > +/*
> > + * FIXME: The length of the list depends on how many
> > + * vCPU is current blocked on this specific pCPU.
> > + * This may hurt the interrupt latency if the list
> > + * grows to too many entries.
> > + */
> > +list_for_each_entry(vmx, &per_cpu(pi_blocked_vcpu, cpu),
> > +pi_blocked_vcpu_list)
> > +if ( vmx->pi_desc.on )
> > +tasklet_schedule(&vmx->pi_vcpu_wakeup_tasklet);
>
> There is a logical bug here. If we have two NV's delivered to this
> pcpu, we will kick the first vcpu twice.
>
> On finding desc.on, a kick should be scheduled, then the vcpu removed
> from this list.
So removing the vCPU from the blocking list here can avoid kicking the
vCPU multiple times, right?
Thanks,
Feng
With desc.on set, we know for certain that another NV
> will not arrive for it until it has been scheduled again and the
> interrupt posted.
>
> ~Andrew
>
> > +
> > +spin_unlock(&per_cpu(pi_blocked_vcpu_lock, cpu));
> > +
> > +ack_APIC_irq();
> > +this_cpu(irq_count)++;
> > +}
> > +
> > const struct hvm_function_table * __init start_vmx(void)
> > {
> > set_in_cr4(X86_CR4_VMXE);
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 59006: regressions - FAIL
flight 59006 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/59006/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 58988 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58988 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58988 version targeted for testing: ovmf 6956ecfe1e70f241f2a861520568bd1c6639ba54 baseline version: ovmf 269e0aebcf978640f16361882f423c7b9593215c People who touched revisions under test: Qiu Shumin jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 6956ecfe1e70f241f2a861520568bd1c6639ba54 Author: Qiu Shumin Date: Tue Jun 30 20:15:15 2015 + ShellPkg: Refine code to make catenae length more precise. This commit refine the catenae length. A too long catenae length in StrnCat may cause potential buffer overflow while in StrnCatS it may ASSERT. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin Reviewed-by: Jaben Carsey git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17747 6f19259b-4bc3-4df7-8a09-765794883524 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] osstest: install libnl3 packages
On 07/01/2015 11:12 PM, Roger Pau Monne wrote:
Install the libnl3 packages needed by the remus code. Those are available on
both Wheezy and Jessie, although the Wheezy ones are too old.
Thanks!
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Shriram Rajagopalan
Cc: Yang Hongyang
---
ts-xen-build-prep | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 9a3b523..034377e 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -206,14 +206,8 @@ sub prep () {
autoconf automake libtool xsltproc
libxml2-utils libxml2-dev
libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
- ccache nasm checkpolicy);
+ ccache nasm checkpolicy libnl-3-dev libnl-route-3-dev);
-if ($ho->{Suite} =~ m/wheezy|squeeze|lenny/) {
What about squeeze|lenny?
- push(@packages, "libnl-dev");
-} else {
- # jessie (>jessie?)
- push(@packages, "libnl-route-3-dev");
-}
target_install_packages($ho, @packages);
target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
# workaround for Debian #595728
--
Thanks,
Yang.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.0 test] 59003: regressions - FAIL
flight 59003 linux-3.0 real [real] http://logs.test-lab.xenproject.org/osstest/logs/59003/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 15418 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 15418 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 15418 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail REGR. vs. 15418 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 15418 Tests which are failing intermittently (not blocking): test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail pass in 58982 test-amd64-i386-xl6 xen-bootfail pass in 58982 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-bootfail pass in 58982 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-multivcpu 6 xen-boot fail baseline untested test-amd64-amd64-xl-rtds 6 xen-bootfail baseline untested test-amd64-amd64-xl-credit2 6 xen-bootfail baseline untested test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail baseline untested test-amd64-i386-freebsd10-i386 6 xen-boot fail baseline untested test-amd64-i386-xl-xsm 15 guest-saverestore.2 fail in 58982 baseline untested test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail in 58982 baseline untested test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 58982 baseline untested test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start.2 fail in 58982 baseline untested test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail in 58982 baseline untested Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-xsm 6 xen-boot fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail never pass test-amd64-amd64-libvirt-xsm 6 xen-boot fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 6 xen-boot fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail never pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: linux5dba9ddd98cbc7ad319d687887981a0ea0062c75 baseline version: linuxe1c63f9f42393f7c1dc072db7e0d54e599e96b46 639 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm
Re: [Xen-devel] [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy
If I'm correct, then #3 means it's not possible to have devices for a domain *default* to strict, but to be relaxed in individual instances. If you had five devices you wanted strict, and only one device you wanted to be relaxed (because you knew it didn't matter), you'd have to set reserved=strict for all the other devices, rather than just being able to set the domain setting to strict and set reserve=relaxed for the one. I think that both violates the principle of least surprise, and is less useful. So what's you idea to follow our requirement? So consider the following config snippet: --- rdm="reserve=relaxed" pci=['01:00.1,msitranslate=1'] What should the policy for that device be? According to your policy document, it seems to me like it should be "relaxed", since the domain default* is set to "relaxed" and nothing Why? "strict" should be in this case. OK, I think I see where the problem is. I had expected the domain-wide setting to be a default which was overridden by per-device policies (see pci_permissive and friends). So when I saw "global default RDM policy" We knew this behavior but we'd like to take a different consideration in this case. confirmation bias caused me to interpret it as what I expected to see -- the domain setting as the default, which the local setting could override. I see now that in your documentation you consistently talk about two different policies, each of which have their own defaults, and that the effective permissions for a device end up being the intersection of the two (i.e., only relaxed of both are relaxed; strict under all other circumstances). Why are you saying this is not our expectation? Just let me pick up that description *again*, "Default per-device RDM policy is 'strict', while default global RDM policy is 'relaxed'. When both policies are specified on a given region, 'strict' is always preferred." Look, if I haven't understood what you meant by the exact same words the first 4 times I read it, simply repeating the same exact words is not going to be helpful. Ideally you need to try go understand where my misunderstanding is coming from and explain where I've misunderstood something; or, at least you need to try to use different words, or explain how the words you're using apply to the given situation. From my point of view, I already replied this previously by quoting part of the patch head description. As you know this revision is already marked as v4 and although I admit some code implementations still need a further review, at least our policy should already acknowledged right now unless this is really wrong. But in our case, looks you're concerning our mechanism is not expected to you. So This interface doesn't make any sense to me. Why, if the "global If you have any objection to our solution, and if you can't find any reasonable answer from our design, just please ping Jan or Kevin because just do it to make this clear to us. And then, whatever, I'm going be fine to step next. I'm really not that person who can address this kind of change at this point in this high level. And you have no idea why that design was chosen; you're just doing what Certainly I have my own understanding with this issue. But you're told? in high level I have to say Yes. If you really read that v2 design and its associated discussion, you should notice I didn't put any response right there. I was involved in the design discussion, and from the very beginning I probably saw your plan but misunderstood it. I wouldn't be surprised if some others didn't quite understand what they were agreeing to. Again, I didn't walk into v2 design. So here I don't want to bring any confusion to you just with my reply. This way of doing things is different than the way we do it with most other options relating to pci devices (e.g., pci_permissive, pci_msitranslate, pci_sieze, &c). All of those options use a "default" semantic: the domain-wide setting takes effect only if it's not set locally. If the syntax looks the same but the semantics is different, many people will be confused. If we're going to have the domain-wide policy override the per-device policy, then the naming should make that clear; for instance, "override=(strict|relaxed|none)", or "strict_override=(1|0)". I don't happen to think these "override" semantics are actually going to turn out to be that useful; I do think a "default" semantic would be useful. But I'd be content if the name of the current setting were switched to "override" to make the semantics more clear. We can always add in "default" at some later point if we really want. Just as I said you'd better ping Jan or Kevin to make a point. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH xen] stubdom: vtpmmgr: Correctly format size_t with %z when printing.
Ian Campbell, le Fri 26 Jun 2015 12:06:09 +0100, a écrit :
> Also contains a fix from Thomas Leonard (to use %u for "4 + 32", not
> %lu) previously posted as part of "mini-os: enable compiler check for
> printk format types" but with mini-os now having been split a separate
> repo most of that change has been applied there.
>
> This fixes the 32-bit build with updated mini-os which includes format
> string checking.
>
> Signed-off-by: Thomas Leonard
> Signed-off-by: Ian Campbell
> Cc: Daniel De Graaf
> Cc: Stefano Stabellini
Acked-By: Samuel Thibault
(after the 'z' modifier support is commited, of course)
> ---
> I intend to fold in an update to MINIOS_UPSTREAM_REVISION upon commit
> to pull in the updated mini-os plus the "Correct printf formatting for
> tpm_tis message." patch I've just posted.
> ---
> stubdom/vtpmmgr/disk_read.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
> index e9dc20f..944d3ff 100644
> --- a/stubdom/vtpmmgr/disk_read.c
> +++ b/stubdom/vtpmmgr/disk_read.c
> @@ -548,18 +548,18 @@ int vtpm_load_disk(void)
> TPM_read_pcrs();
>
> printk("TPM Manager - disk format %d\n", TPM_MGR_VERSION);
> - printk(" root seal: %lu; sector of %d: %lu\n",
> + printk(" root seal: %zu; sector of %d: %zu\n",
> sizeof(struct disk_root_sealed_data), SEALS_PER_ROOT_SEAL_LIST,
> sizeof(struct disk_seal_list));
> - printk(" root: %lu v=%lu\n", sizeof(root1), sizeof(root1.v));
> - printk(" itree: %lu; sector of %d: %lu\n",
> + printk(" root: %zu v=%zu\n", sizeof(root1), sizeof(root1.v));
> + printk(" itree: %u; sector of %d: %zu\n",
> 4 + 32, NR_ENTRIES_PER_ITREE, sizeof(struct disk_itree_sector));
> - printk(" group: %lu v=%lu id=%lu md=%lu\n",
> + printk(" group: %zu v=%zu id=%zu md=%zu\n",
> sizeof(struct disk_group_sector), sizeof(struct
> disk_group_sector_mac3_area),
> sizeof(struct group_id_data), sizeof(struct group_details));
> - printk(" group seal: %lu; %d in parent: %lu; sector of %d: %lu\n",
> + printk(" group seal: %zu; %d in parent: %zu; sector of %d: %zu\n",
> sizeof(struct disk_group_sealed_data), NR_SEALS_PER_GROUP,
> sizeof(struct disk_group_boot_config_list),
> SEALS_PER_GROUP_SEAL_LIST, sizeof(struct disk_group_seal_list));
> - printk(" vtpm: %lu+%lu; sector of %d: %lu\n",
> + printk(" vtpm: %zu+%zu; sector of %d: %zu\n",
> sizeof(struct disk_vtpm_plain), sizeof(struct disk_vtpm_secret),
> VTPMS_PER_SECTOR, sizeof(struct disk_vtpm_sector));
>
> --
> 1.7.10.4
>
--
Samuel
/* Amuse the user. */
printk(
" \\|/ \\|/\n"
" \"@'/ ,. \\`@\"\n"
" /_| \\__/ |_\\\n"
" \\__U_/\n");
(From linux/arch/sparc/kernel/traps.c:die_if_kernel())
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH mini-os] Correct printf formatting for tpm_tis message.
Ian Campbell, le Fri 26 Jun 2015 11:58:40 +0100, a écrit :
> This is under #ifdef HAVE_LIBC so went unnoticed before.
>
> Signed-off-by: Ian Campbell
Acked-by: Samuel Thibault
> ---
> tpm_tis.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tpm_tis.c b/tpm_tis.c
> index 98fe837..475ac5d 100644
> --- a/tpm_tis.c
> +++ b/tpm_tis.c
> @@ -1429,7 +1429,7 @@ struct tpm_chip* init_tpm2_tis(unsigned long baseaddr,
> int localities, unsigned
>
> /* Map the page in now */
> if ((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
> -printk("Unable to map iomem page a address %p\n", addr);
> +printk("Unable to map iomem page a address %lx\n", addr);
> goto abort_egress;
> }
>
> --
> 1.7.10.4
>
--
Samuel
d-_-b
how u make that inverted b?
wait
never mind
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 59004: regressions - FAIL
flight 59004 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/59004/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 11 guest-start fail REGR. vs. 58842 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 11 guest-start fail like 58842 test-amd64-amd64-libvirt 11 guest-start fail like 58842 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: libvirt 04597f8f0de09cbac5a141bee6f6690924900bc8 baseline version: libvirt d10a5f58c75e7eb5943b44cc36a1e768adb2cdb0 People who touched revisions under test: Andrea Bolognani Boris Fiuczynski Dmitry Guryanov Eric Blake Jim Fehlig Jiri Denemark John Ferlan Ján Tomko Laine Stump Luyao Huang Martin Kletzander Michal Privoznik Mikhail Feoktistov Nikolay Shirokovskiy Nikolay Shirokovskiy Peter Krempa Prerna Saxena jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt pass test-amd64-i386-libvirt fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1205 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 59001: regressions - FAIL
flight 59001 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/59001/ 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. 58581 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 11 guest-start fail like 58581 test-armhf-armhf-xl-multivcpu 6 xen-boot fail like 58581 test-armhf-armhf-xl-credit2 6 xen-boot fail like 58581 test-armhf-armhf-xl 6 xen-boot fail like 58581 test-armhf-armhf-libvirt-xsm 6 xen-boot fail like 58581 test-armhf-armhf-xl-xsm 6 xen-boot fail like 58581 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58581 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58581 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58581 Tests which did not succeed, but are not blocking: test-amd64-i386-freebsd10-amd64 9 freebsd-install fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-freebsd10-i386 9 freebsd-install fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: linuxea5dd38e93b3bec3427e5d3eef000bbf5d637e76 baseline version: linuxd048c068d00da7d4cfa5ea7651933b99026958cf People who touched revisions under test: "Eric W. Biederman" Aaron Lu Alexander Duyck Alexei Starovoitov Andrew de los Reyes Andrew Morton Andy Lutomirski Anna Schumaker Aravind Gopalakrishnan Ard Biesheuvel Arnd Bergmann Baruch Siach Ben Serebrin Benjamin Tissoires Bjørn Mork Borislav Petkov Chuck Lever Cong Wang Daniel Borkmann Darren Hart Darren Salt David Daney David S. Miller David Woodhouse Devesh Sharma Doug Ledford Eric Dumazet Eric W. Biederman Felipe Balbi Feng Kan Florent Fourcot Florian Fainelli Geert Uytterhoeven Grant Likely Greg Kroah-Hartman Hannes Frederic Sowa Henning Rogge Honggang Li Ian Campbell Ilya Dryomov Ingo Molnar Jakub Sitnicki Jason Gunthorpe Jiada Wang Jiri Kosina Jiri Pirko Joerg Roedel Jovi Zhangwei Ken Xue Kevin Hilman Konstantin Khlebnikov Laura Abbott Laurent Pinchart Linus Lüssing Linus Torvalds Linus Walleij Mark Brown Mark Salyzyn Matt Fleming Matthew Garrett Mauro Carvalho Chehab Max Filippov Meghana Cheripady Mel Gorman Mika Westerberg Milan Plzik Neal Cardwell Neil Horman Nicolas Dichtel Nicolas Iooss Nicolas Pitre Nikolay Aleksandrov Oliver Neukum Oliver Neukum oli...@neukum.org Olof Johansson Pablo Neira Ayuso Paolo Bonzini Pelle Nilsson Peter Zijlstra (Intel) Rafael J. Wysocki Raphael Assenat Richard Cochran Rik Theys Ross Lagerwall Roy Franz Russell King Sasha Levin Sean Young Shawn Bohrer Simon Horman Sowmini Varadhan Sriharsha Basavapatna Steffen Klassert Thadeu Lima de Souza Cascardo Theodore Ts'o Uwe Kleine-König Veaceslav Falico Veeresh U. Kokatnur Vijay Subramanian Vinod Koul Vittorio Gambaletta Vlad Yasevich Vladislav Yasevich WANG Cong Wei Liu Yao Xiwei Yoshihiro Shimoda Yuchung Cheng jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvops
[Xen-devel] [xen-unstable test] 58999: regressions - FAIL
flight 58999 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/58999/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail like 58958 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail like 58958 test-amd64-i386-libvirt-xsm 11 guest-start fail like 58965 test-amd64-i386-libvirt 11 guest-start fail like 58965 test-amd64-amd64-libvirt-xsm 11 guest-start fail like 58965 test-amd64-amd64-libvirt 11 guest-start fail like 58965 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58965 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-rtds 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 2804137167ca3f9c0d4feb173a46a90ebe747cda baseline version: xen c40317f11b3f05e7c06a2213560c8471081f2662 People who touched revisions under test: Andrew Cooper Ard Biesheuvel Dario Faggioli George Dunlap Ian Campbell Ian Jackson Jan Beulich Julien Grall Liang Li Tiejun Chen Wei Liu Wen Congyang Yang Zhang jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-a
Re: [Xen-devel] [PATCH v6] run QEMU as non-root
On 07/01/2015 09:34 AM, Stefano Stabellini wrote: On Wed, 1 Jul 2015, Dario Faggioli wrote: On Wed, 2015-07-01 at 13:50 +0100, Stefano Stabellini wrote: --- /dev/null +++ b/docs/misc/qemu-deprivilege.txt @@ -0,0 +1,31 @@ +For security reasons, libxl tries to pass a non-root username to QEMU as +argument. During initialization QEMU calls setuid and setgid with the +user ID and the group ID of the user passed as argument. +Libxl looks for the following users in this order: + +1) a user named "xen-qemuuser-domid$domid", +Where $domid is the domid of the domain being created. +This requires the reservation of 65535 uids from xen-qemuuser-domid1 +to xen-qemuuser-domid65535. To use this mechanism, you might want to +create a large number of users at installation time. For example: + +for ((i=1; i<65536; i++)) +do +adduser --no-create-home --system xen-qemuuser-domid$i +done + +You might want to consider passing --group to adduser to create a new +group for each new user. + This is, IMHO, a lot of policing, for something like libxl. I'm saying this only now because, although always being always dubious about it, it was Jim's comment to v5 that made me realize it properly, and you're own reply to him in that thread, would actually be a great alternative! In fact, what about: * in libxl: - provide and honour (as first option) device_model_user, as you're doing here; - if the above is not provided, check the availability of the 'shared' user, and use it if it's there; - if that is not there either, use root. * in xl (as you said yourself in v5's review): - build up the per-domain username and (if available) use device_model_user to pass it to libxl. That is of course possible and was my first suggestion in my reply. However after speaking with IanC, I was convinced that offering a good default security mechanism in libxl is better, so that all libxl users, including hyper for example, get good security by default without any need to do anything (except creating some users). I think that libvirt is a bit of a special case here, given that it already knows about users. I would expect most other toolstacks not to. Perhaps. But thanks for providing a way (b_info->device_model_user) for apps to override the libxl policy. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 58997: regressions - trouble: broken/fail/pass
flight 58997 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/58997/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf-pin 6 xen-boot fail in 58831 pass in 58798 test-amd64-amd64-xl 6 xen-boot fail in 58955 pass in 58941 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 58798 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 58798 test-amd64-i386-pair 10 xen-boot/dst_host fail pass in 58831 test-amd64-i386-pair 9 xen-boot/src_host fail pass in 58831 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail pass in 58955 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl 3 host-install(3) broken like 30496 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-i386-libvirt-xsm 6 xen-bootfail baseline untested test-amd64-amd64-xl-multivcpu 6 xen-boot fail baseline untested test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-libvirt-xsm 6 xen-bootfail baseline untested test-amd64-amd64-xl-credit2 6 xen-bootfail baseline untested test-amd64-amd64-xl-xsm 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail baseline untested test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-sedf 6 xen-boot fail in 58831 like 30406 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail in 58955 baseline untested test-amd64-i386-libvirt 11 guest-start fail like 30511 test-amd64-amd64-libvirt 11 guest-start fail like 30511 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 30511 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 30511 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect test-amd64-i386-xl6 xen-bootfail like 53725-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail like 58780-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail like 58786-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-bootfail like 58788-bisect test-amd64-i386-rumpuserxen-i386 6 xen-bootfail like 58799-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-bootfail like 58801-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail like 58803-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail like 58804-bisect test-amd64-i386-freebsd10-i386 6 xen-boot fail like 58805-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail like 58806-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail like 58807-bisect test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail like 58808-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-bootfail like 58809-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-boot fail like 58810-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-bootfail like 58811-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail like 58813-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-bootfail like 58814-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-bootfail like 58815-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 12 migrate-support-check fail in 58831 never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 58831 never pass test-amd64-amd64-libvirt 12 migrate-support-check fail in 58831 never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 58955 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass version targeted for testing: linuxcf1b3dad6c5699b977273276bada8597636ef3e2 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 500 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm
Re: [Xen-devel] [PATCH v12 7/8] Add IOREQ_TYPE_VMWARE_PORT
On Sat, Jun 27, 2015 at 07:27:44PM -0400, Don Slutz wrote:
> From: Don Slutz
>
> This adds synchronization of the 6 vcpu registers (only 32bits of
> them) that vmport.c needs between Xen and QEMU.
>
> This is to avoid a 2nd and 3rd exchange between QEMU and Xen to
> fetch and put these 6 vcpu registers used by the code in vmport.c
> and vmmouse.c
>
> In the tools, enable usage of QEMU's vmport code.
>
> The currently most useful VMware port support that QEMU has is the
> VMware mouse support. Xorg included a VMware mouse support that
> uses absolute mode. This make using a mouse in X11 much nicer.
>
> Signed-off-by: Don Slutz
> Acked-by: Ian Campbell
> CC: Don Slutz
> ---
> v12:
> Rebase changes.
>
> Pass size to vmport_check_port() -- required if overlap
> I.E. inl on port 0x5657, 0x5656, 0x5655, 0x5659, 0x565a,
> and 0x565b.
>
> Move define of vmport_check_port() into this patch from ring3
> patch.
>
> v11:
> No change
>
> v10:
> These literals should become an enum.
> I don't think the invalidate type is needed.
> Code handling "case X86EMUL_UNHANDLEABLE:" in emulate.c
> is unclear.
> Comment about "special' range of 1" is not clear.
>
>
> v9:
> New code was presented as an RFC before this.
>
> Paul Durrant sugested I add support for other IOREQ types
> to HVMOP_map_io_range_to_ioreq_server.
> I have done this.
>
> tools/libxc/xc_hvm_build_x86.c | 5 +-
> tools/libxl/libxl_dm.c | 2 +
> xen/arch/x86/hvm/emulate.c | 83 +++---
> xen/arch/x86/hvm/hvm.c | 182
> ++-
> xen/arch/x86/hvm/io.c| 16
> xen/arch/x86/hvm/vmware/vmport.c | 13 +++
> xen/include/asm-x86/hvm/domain.h | 3 +-
> xen/include/asm-x86/hvm/hvm.h| 2 +
> xen/include/public/hvm/hvm_op.h | 5 ++
> xen/include/public/hvm/ioreq.h | 17
> xen/include/public/hvm/params.h | 4 +-
> 11 files changed, 293 insertions(+), 39 deletions(-)
>
> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> index 003ea06..feebbf7 100644
> --- a/tools/libxc/xc_hvm_build_x86.c
> +++ b/tools/libxc/xc_hvm_build_x86.c
> @@ -46,7 +46,8 @@
> #define SPECIALPAGE_IOREQ5
> #define SPECIALPAGE_IDENT_PT 6
> #define SPECIALPAGE_CONSOLE 7
> -#define NR_SPECIAL_PAGES 8
> +#define SPECIALPAGE_VMPORT_REGS 8
> +#define NR_SPECIAL_PAGES 9
> #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
>
> #define NR_IOREQ_SERVER_PAGES 8
> @@ -610,6 +611,8 @@ static int setup_guest(xc_interface *xch,
> special_pfn(SPECIALPAGE_BUFIOREQ));
> xc_hvm_param_set(xch, dom, HVM_PARAM_IOREQ_PFN,
> special_pfn(SPECIALPAGE_IOREQ));
> +xc_hvm_param_set(xch, dom, HVM_PARAM_VMPORT_REGS_PFN,
> + special_pfn(SPECIALPAGE_VMPORT_REGS));
> xc_hvm_param_set(xch, dom, HVM_PARAM_CONSOLE_PFN,
> special_pfn(SPECIALPAGE_CONSOLE));
> xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 975996d..966ca46 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -831,6 +831,8 @@ static int libxl__build_device_model_args_new(libxl__gc
> *gc,
> machinearg, max_ram_below_4g);
> }
> }
> +if (libxl_defbool_val(c_info->vmware_port))
> +machinearg = GCSPRINTF("%s,vmport=on", machinearg);
> flexarray_append(dm_args, machinearg);
> for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
> flexarray_append(dm_args, b_info->extra_hvm[i]);
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index fe5661d..51a97d5 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -169,33 +169,88 @@ static int hvmemul_do_io(
> vio->io_state = HVMIO_handle_mmio_awaiting_completion;
> break;
> case X86EMUL_UNHANDLEABLE:
> -{
> -struct hvm_ioreq_server *s =
> -hvm_select_ioreq_server(curr->domain, &p);
> -
> -/* If there is no suitable backing DM, just ignore accesses */
> -if ( !s )
> +if ( vmport_check_port(p.addr, p.size) )
I would have made this !. Thought if Jan or Andrew said to make it that
way - then please ignore me.
That would mean you could also change the function to be 'is_port_vmport' or
such.
> {
> -hvm_complete_assist_req(&p);
> -rc = X86EMUL_OKAY;
> -vio->io_state = HVMIO_none;
> +struct hvm_ioreq_server *s =
> +hvm_select_ioreq_server(curr->domain, &p);
> +
> +/* If there is no suitable backing DM, just ignore accesses */
> +if ( !s )
> +{
> +hvm_complete_assist_req(&p);
> +rc = X86EMUL_OKAY;
> +vio->io_
Re: [Xen-devel] [PATCH v5] run QEMU as non-root
On 07/01/2015 02:23 AM, Fabio Fantoni wrote:
Il 01/07/2015 02:04, Jim Fehlig ha scritto:
On 06/30/2015 07:55 AM, Stefano Stabellini wrote:
Try to use "xen-qemudepriv-domid$domid" first, then
"xen-qemudepriv-shared" and root if everything else fails.
The uids need to be manually created by the user or, more likely, by the
xen package maintainer.
To actually secure QEMU when running in Dom0, we need at least to
deprivilege the privcmd and xenstore interfaces, this is just the first
step in that direction.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- improve wording in doc
- fix wording in warning message
- fix example in doc
- drop xen-qemudepriv-$domname
Changes in v4:
- rename qemu-deprivilege to qemu-deprivilege.txt
- add a note about qemu-deprivilege.txt to INSTALL
- instead of xen-qemudepriv-base + $domid, try xen-qemudepriv-domid$domid
- introduce libxl__dm_runas_helper to make the code nicer
Changes in v3:
- clarify doc
- handle errno == ERANGE
---
INSTALL|7 ++
docs/misc/qemu-deprivilege.txt | 26 +
tools/libxl/libxl_dm.c | 50
tools/libxl/libxl_internal.h |4
4 files changed, 87 insertions(+)
create mode 100644 docs/misc/qemu-deprivilege.txt
diff --git a/INSTALL b/INSTALL
index a0f2e7b..fe83c20 100644
--- a/INSTALL
+++ b/INSTALL
@@ -297,6 +297,13 @@ systemctl enable xendomains.service
systemctl enable xen-watchdog.service
+QEMU Deprivilege
+
+It is recommended to run QEMU as non-root.
+See docs/misc/qemu-deprivilege.txt for an explanation on what you need
+to do at installation time to run QEMU as a dedicated user.
+
+
History of options
==
diff --git a/docs/misc/qemu-deprivilege.txt b/docs/misc/qemu-deprivilege.txt
new file mode 100644
index 000..783874b
--- /dev/null
+++ b/docs/misc/qemu-deprivilege.txt
@@ -0,0 +1,26 @@
+For security reasons, libxl tries to create QEMU as non-root.
+Libxl looks for the following users in this order:
+
+1) a user named "xen-qemuuser-domid$domid",
+Where $domid is the domid of the domain being created.
+This requires the reservation of 65535 uids from xen-qemuuser-domid1
+to xen-qemuuser-domid65535. To use this mechanism, you might want to
+create a large number of users at installation time. For example:
+
+for ((i=1; i<65536; i++))
+do
+adduser --system xen-qemuuser-domid$i
+done
+
+
+2) a user named "xen-qemuuser-shared"
+As a fall back if both 1) and 2) fail, libxl will use a single user for
+all QEMU instances. The user is named xen-qemuuser-shared. This is
+less secure but still better than running QEMU as root. Using this is as
+simple as creating just one more user on your host:
+
+adduser --system xen-qemuuser-shared
+
+
+3) root
+As a last resort, libxl will start QEMU as root.
The more I think about it, the more I feel libxl is the wrong place for this
policy. As mentioned earlier [0], libvirt allows apps to control the
user:group policy. It is already supported by the qemu driver. It could be
used by the libxl driver to inform libxl that the emulator (and other
binaries?) it spawns should be in the context of the specified user:group.
Regards,
Jim
In the patch I saw this:
+if (user) {
+flexarray_append(dm_args, "-runas");
+flexarray_append(dm_args, user);
+}
So seems that already use qemu parameter for it.
What you mean is to add also the possibility to specify user for use it from
libvirt and similar instead doing a different thing to support the xen
specific one?
Yes.
If yes I also think can be a good idea. In that case can you explain a better
way to do it? Probably Stabellini didn't done it because don't know other
similar implementation already present in other systems that use qemu and how
are good and used.
I replied to Stefano's mail with some additional thoughts and ideas, but I think
he understands.
Regards,
Jim
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 3/8] tools: Add vmware_hwver support
On Sat, Jun 27, 2015 at 07:27:40PM -0400, Don Slutz wrote: > From: Don Slutz > > This is used to set xen_arch_domainconfig vmware_hw. It is set to > the emulated VMware virtual hardware version. > > Currently 0, 3-4, 6-11 are good values. However the code only > checks for == 0, != 0, or < 7. > > Signed-off-by: Don Slutz > CC: Don Slutz > --- > v12: > I'm not sure this hunk has anything to do with this patch, nor > what the semantic difference between the old and new text is > supposed to be. > Dropped comment change. > > > v11: > Dropped "If non-zero then default VGA to VMware's VGA" > > v10: > LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE & > LIBXL_HAVE_BUILDINFO_HVM_VMWARE_HWVER are arriving together > a single umbrella could be used. > Since I split the LIBXL_VGA_INTERFACE_TYPE_VMWARE into > it's own patch, this is not longer true. > But I did use 1 for the 2 c_info changes. > Please use GCSPRINTF. > Remove vga=vmware from here. > > v9: > I assumed that s/vmware_hw/vmware_hwver/ is not a big enough > change to drop the Reviewed-by. Did a minor edit to the > commit message to add 7 to the list of values checked. > > v7: > Default handling of hvm.vga.kind bad. > Fixed. > Default of vmware_port should be based on vmware_hw. > Done. > > v5: > Anything looking for Xen according to the Xen cpuid instructions... > Adjusted doc to new wording. > > docs/man/xl.cfg.pod.5 | 17 + > tools/libxl/libxl_create.c | 4 +++- > tools/libxl/libxl_types.idl | 1 + > tools/libxl/libxl_x86.c | 3 +-- > tools/libxl/xl_cmdimpl.c| 2 ++ > 5 files changed, 24 insertions(+), 3 deletions(-) > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > index 84078f6..4a01527 100644 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -1348,6 +1348,23 @@ The viridian option can be specified as a boolean. A > value of true (1) > is equivalent to the list [ "defaults" ], and a value of false (0) is > equivalent to an empty list. > > +=item B > + > +Turns on or off the exposure of VMware cpuid. The number is > +VMware's hardware version number, where 0 is off. A number >= 7 > +is needed to enable exposure of VMware cpuid. > + > +The hardware version number (vmware_hwver) comes from VMware config files. > + > +=over 4 > + > +In a .vmx it is virtualHW.version > + > +In a .ovf it is part of the value of vssd:VirtualSystemType. > +For vssd:VirtualSystemType == vmx-07, vmware_hwver = 7. > + > +=back > + Perhaps add 'Recommended value is 7' ? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 2/8] xen: Add support for VMware cpuid leaves
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index ed2bd38..651b338 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -5,8 +5,8 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>libxl_domain_config *d_config,
>xc_domain_configuration_t *xc_config)
> {
> -/* No specific configuration right now */
> -
> +/* Note: will be changed in a later patch */
One usually say which patch. Also missing '.'.
> +xc_config->vmware_hwver = 0;
> return 0;
> }
>
... snip..
> diff --git a/xen/arch/x86/hvm/vmware/cpuid.c b/xen/arch/x86/hvm/vmware/cpuid.c
> new file mode 100644
> index 000..0dff36b
> --- /dev/null
> +++ b/xen/arch/x86/hvm/vmware/cpuid.c
> @@ -0,0 +1,77 @@
> +/*
> + * arch/x86/hvm/vmware/cpuid.c
> + *
> + * Copyright (C) 2012 Verizon Corporation
s/2012/2015/ ?
> + *
> + * This file is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License Version 2 (GPLv2)
> + * as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Wed, Jul 01, 2015 at 11:29:46AM +0100, Stefano Stabellini wrote: > On Tue, 30 Jun 2015, Konrad Rzeszutek Wilk wrote: > > On Tue, Jun 30, 2015 at 03:13:53PM +0100, Ian Campbell wrote: > > > On Tue, 2015-06-30 at 15:02 +0100, Stefano Stabellini wrote: > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > > > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > > > > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano > > > > > > > > > > > Stabellini wrote: > > > > > > > > > > > > When QEMU restricts its xenstore connection, it cannot > > > > > > > > > > > > provide PV > > > > > > > > > > > > backends. A separate QEMU instance is required to > > > > > > > > > > > > provide PV backends in > > > > > > > > > > > > userspace, such as qdisk. With two separate instances, > > > > > > > > > > > > it is not > > > > > > > > > > > > possible to take advantage of vkb for mouse and > > > > > > > > > > > > keyboard, as the QEMU > > > > > > > > > > > > that emulates the graphic card (the device model), > > > > > > > > > > > > would be separate > > > > > > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question is that how would this affect the non-split > > > > > > > > > > > setup. > > > > > > > > > > > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up > > > > > > > > > > more often. > > > > > > > > > > However there is no way around it. > > > > > > > > > > > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > > > > > > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > > > > > > > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV > > > > > > > > > input > > > > > > > > > devices? > > > > > > > > > > > > > > > > VGA + PV input only works with Linux and is only useful for > > > > > > > > power > > > > > > > > efficiency, because if you disable usb emulation in QEMU, then > > > > > > > > QEMU > > > > > > > > would be able to wake up less often. Given that usb emulation > > > > > > > > is still > > > > > > > > on by default, I don't think that this change will have a big > > > > > > > > impact. > > > > > > > > > > > > > > My question was whether we thought anyone would be using this > > > > > > > non-default configuration, not what the impact on the default is. > > > > > > > > > > > > > > You gave a good reason why people might be using this facility, > > > > > > > do you > > > > > > > think anyone is actually using it? > > > > > > > > > > > > I don't know of anybody using it. I don't think we made clear > > > > > > enough how > > > > > > to use this non-default configuration and its advantages for users > > > > > > to go > > > > > > out of their ways to use it. > > > > > > > > > > That's good enough for me, thanks,. > > > > > > > > Can I add your acked-by? > > > > > > If you put some distillation of the reasoning given in this subthread > > > for why we think we can get away with it into the commit message then > > > yes. > > > > Why don't we also make the Linux code not expose this driver for HVM guests? > > > > I've had an go for this last year (can't find the link) as it would unduly And the link: http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg00160.html > > cause the Linux kernel to take an extra 30 seconds to boot. That is because > > 'xend' by default exposes the PV configuration even for HVM guests - and of > > course there are no PV drivers (as the VGA in QEMU is enabled). > > But even with xend it only happens with a vfb line is in the config > file, right? That's why we didn't fix it back when the issue was > reported, if I remember correctly. Both. If you had 'vnc' or 'vfb' it would setup the 'vfb' key. > > > > The only use case I had was for ARM - where there are no VGA - and the > > patch I think I had just disabled the xen-fbfront under X86 HVM. > > Yeah, we need xen-fbfront for ARM. > > > Given that xen-fbfront is likely to go away for HVM guests, I wouldn't > be opposed to stop the driver initialization in Linux on x86/HVM. Unless > Roger's work on HVMlite is going to need xen-fbfront again, but in that > case we'll be able to distinguish a regular HVM guest from an HVMlite > guest, I think. Correct. Right now the 'xen_pvh_domain' is based on it being PV and auto-translate. That whole thing will need some help. But I am looking at the xen-fbfront.c driver and it might be that I had already fixed this issue! (inadvertly it seems) 51c71a3bbaca868043cc45b3ad3786dd48a90235 Author: Konrad Rzeszutek Wilk Date: T
[Xen-devel] [PATCH 3.14 03/34] config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected
3.14-stable review patch. If anyone has any objections, please let me know. -- From: Konrad Rzeszutek Wilk commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d upstream. A huge amount of NIC drivers use the DMA API, however if compiled under 32-bit an very important part of the DMA API can be ommitted leading to the drivers not working at all (especially if used with 'swiotlb=force iommu=soft'). As Prashant Sreedharan explains it: "the driver [tg3] uses DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma "mapping" and dma_unmap_addr() to get the "mapping" value. On most of the platforms this is a no-op, but ... with "iommu=soft and swiotlb=force" this house keeping is required, ... otherwise we pass 0 while calling pci_unmap_/pci_dma_sync_ instead of the DMA address." As such enable this even when using 32-bit kernels. Reported-by: Ian Jackson Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David S. Miller Acked-by: Prashant Sreedharan Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Michael Chan Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: casca...@linux.vnet.ibm.com Cc: david.vra...@citrix.com Cc: sanje...@broadcom.com Cc: siva.kal...@broadcom.com Cc: vyasev...@gmail.com Cc: xen-de...@lists.xensource.com Link: http://lkml.kernel.org/r/20150417190448.ga9...@l.oracle.com Signed-off-by: Ingo Molnar Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman --- arch/x86/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -160,7 +160,7 @@ config SBUS config NEED_DMA_MAP_STATE def_bool y - depends on X86_64 || INTEL_IOMMU || DMA_API_DEBUG + depends on X86_64 || INTEL_IOMMU || DMA_API_DEBUG || SWIOTLB config NEED_SG_DMA_LENGTH def_bool y ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3.10 03/22] config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Konrad Rzeszutek Wilk commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d upstream. A huge amount of NIC drivers use the DMA API, however if compiled under 32-bit an very important part of the DMA API can be ommitted leading to the drivers not working at all (especially if used with 'swiotlb=force iommu=soft'). As Prashant Sreedharan explains it: "the driver [tg3] uses DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma "mapping" and dma_unmap_addr() to get the "mapping" value. On most of the platforms this is a no-op, but ... with "iommu=soft and swiotlb=force" this house keeping is required, ... otherwise we pass 0 while calling pci_unmap_/pci_dma_sync_ instead of the DMA address." As such enable this even when using 32-bit kernels. Reported-by: Ian Jackson Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David S. Miller Acked-by: Prashant Sreedharan Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Michael Chan Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: casca...@linux.vnet.ibm.com Cc: david.vra...@citrix.com Cc: sanje...@broadcom.com Cc: siva.kal...@broadcom.com Cc: vyasev...@gmail.com Cc: xen-de...@lists.xensource.com Link: http://lkml.kernel.org/r/20150417190448.ga9...@l.oracle.com Signed-off-by: Ingo Molnar Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman --- arch/x86/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -154,7 +154,7 @@ config SBUS config NEED_DMA_MAP_STATE def_bool y - depends on X86_64 || INTEL_IOMMU || DMA_API_DEBUG + depends on X86_64 || INTEL_IOMMU || DMA_API_DEBUG || SWIOTLB config NEED_SG_DMA_LENGTH def_bool y ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/13] x86/altp2m: alternate p2m memory events.
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 58d4951..576b28d 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1514,6 +1514,13 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
> }
> }
>
> +void p2m_altp2m_check(struct vcpu *v, const vm_event_response_t *rsp)
> +{
> +if ( (rsp->flags & VM_EVENT_FLAG_ALTERNATE_P2M) &&
>
Please keep the check for (rsp->flags & VM_EVENT_FLAG_ALTERNATE_P2M) in
common/vm_event.c. With that you also only have to pass the altp2m_idx here.
> + altp2m_active(v->domain) )
> +p2m_switch_vcpu_altp2m_by_id(v, rsp->altp2m_idx);
> +}
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 120a78a..57095d8 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -399,6 +399,9 @@ void vm_event_resume(struct domain *d, struct
> vm_event_domain *ved)
>
> };
>
> +/* Check for altp2m switch */
> +p2m_altp2m_check(v, &rsp);
>
See my comment above.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5] dmar: device scope mem leak fix
From: Elena Ufimtseva
Release memory allocated for scope.devices when disabling
dmar units. Also set device count after memory allocation when
device scope parsing.
This is explanation of why the code should be moved imho and
answers Jan question about why I needed to do this.
In acpi_parse_one_drhr move call to acpi_parse_dev_scope after include_all
check so the return value does not get overwritten by calling
acpi_parse_dev_scope.
Signed-off-by: Elena Ufimtseva
---
Changes in v5;
- make scope_devices_free actually safe;
Changes in v4:
- make scope_devices_free safe to call with NULL scope pointer;
- since scope_devices_free is safe to call, use it in failure path
in acpi_parse_one_drhd;
Changes in v3:
- make freeing memory for scope devices and zeroing device counter
as a function;
- make sure parse_one_rmrr has memory leak fix in this patch;
- make sure ret values are not lost acpi_parse_one_drhd;
Changes in v2:
- release memory for devices scope on error paths in acpi_parse_one_drhd
and acpi_parse_one_atsr and set the count to zero;
xen/drivers/passthrough/vtd/dmar.c | 40 ++
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 2b07be9..d187ae2 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -81,6 +81,15 @@ static int __init acpi_register_rmrr_unit(struct
acpi_rmrr_unit *rmrr)
return 0;
}
+static void scope_devices_free(struct dmar_scope *scope)
+{
+if ( !scope )
+return;
+
+scope->devices_cnt = 0;
+xfree(scope->devices);
+}
+
static void __init disable_all_dmar_units(void)
{
struct acpi_drhd_unit *drhd, *_drhd;
@@ -90,16 +99,19 @@ static void __init disable_all_dmar_units(void)
list_for_each_entry_safe ( drhd, _drhd, &acpi_drhd_units, list )
{
list_del(&drhd->list);
+scope_devices_free(&drhd->scope);
xfree(drhd);
}
list_for_each_entry_safe ( rmrr, _rmrr, &acpi_rmrr_units, list )
{
list_del(&rmrr->list);
+scope_devices_free(&rmrr->scope);
xfree(rmrr);
}
list_for_each_entry_safe ( atsr, _atsr, &acpi_atsr_units, list )
{
list_del(&atsr->list);
+scope_devices_free(&atsr->scope);
xfree(atsr);
}
}
@@ -318,13 +330,13 @@ static int __init acpi_parse_dev_scope(
if ( (cnt = scope_device_count(start, end)) < 0 )
return cnt;
-scope->devices_cnt = cnt;
if ( cnt > 0 )
{
scope->devices = xzalloc_array(u16, cnt);
if ( !scope->devices )
return -ENOMEM;
}
+scope->devices_cnt = cnt;
while ( start < end )
{
@@ -427,7 +439,7 @@ static int __init acpi_parse_dev_scope(
out:
if ( ret )
-xfree(scope->devices);
+scope_devices_free(scope);
return ret;
}
@@ -474,12 +486,10 @@ acpi_parse_one_drhd(struct acpi_dmar_header *header)
ret = iommu_alloc(dmaru);
if ( ret )
-goto out;
-
-dev_scope_start = (void *)(drhd + 1);
-dev_scope_end = ((void *)drhd) + header->length;
-ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,
- &dmaru->scope, DMAR_TYPE, drhd->segment);
+{
+xfree(dmaru);
+return ret;
+}
if ( dmaru->include_all )
{
@@ -495,7 +505,13 @@ acpi_parse_one_drhd(struct acpi_dmar_header *header)
if ( drhd->segment == 0 )
include_all = 1;
}
+if ( ret )
+goto out;
+dev_scope_start = (void *)(drhd + 1);
+dev_scope_end = ((void *)drhd) + header->length;
+ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,
+ &dmaru->scope, DMAR_TYPE, drhd->segment);
if ( ret )
goto out;
else if ( force_iommu || dmaru->include_all )
@@ -542,6 +558,7 @@ acpi_parse_one_drhd(struct acpi_dmar_header *header)
" Workaround BIOS bug: ignore the DRHD due to all "
"devices under its scope are not PCI discoverable!\n");
+scope_devices_free(&dmaru->scope);
iommu_free(dmaru);
xfree(dmaru);
}
@@ -562,9 +579,11 @@ acpi_parse_one_drhd(struct acpi_dmar_header *header)
out:
if ( ret )
{
+scope_devices_free(&d
Re: [Xen-devel] [PATCH RFC 4/6] xen: Print and use errno where applicable.
On Wed, Jul 01, 2015 at 02:01:07PM +0100, Stefano Stabellini wrote:
> On Mon, 29 Jun 2015, Konrad Rzeszutek Wilk wrote:
> > In Xen 4.6 commit cd2f100f0f61b3f333d52d1737dd73f02daee592
> > "libxc: Fix do_memory_op to return negative value on errors"
> > made the libxc API less odd-ball: On errors, return value is
> > -1 and error code is in errno. On success the return value
> > is either 0 or an positive value.
> >
> > Since we could be running with an old toolstack in which the
> > Exx value is in rc or the newer, we print both and return
> > the -EXX depending on rc == -1 condition.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk
> > ---
> > xen-hvm.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen-hvm.c b/xen-hvm.c
> > index 0408462..a92bc14 100644
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -345,11 +345,12 @@ go_physmap:
> > unsigned long idx = pfn + i;
> > xen_pfn_t gpfn = start_gpfn + i;
> >
> > +/* In Xen 4.6 rc is -1 and errno contains the error value. */
> > rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn,
> > idx, gpfn);
> > if (rc) {
> > DPRINTF("add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
> > -PRI_xen_pfn" failed: %d\n", idx, gpfn, rc);
> > -return -rc;
> > +PRI_xen_pfn" failed: %d (errno: %d)\n", idx, gpfn, rc,
> > errno);
> > +return rc == -1 ? -errno : -rc;
>
> Printing both rc and errno is the right thing to do, but I am not sure
> changing return value depending on the libxc version is a good idea.
> Maybe we should be consistent and always return rc?
In Xen 4.5 and earlier this function would return -EINVAL (say rc=EINVAL).
With Xen 4.6 it would always return 1 on errors (rc is -1, and with --1 we get
1), while
the errno would have EINVAL.
To be consistent and have this function return an proper -Exx value we
need that check to use errno in case rc == -1.
I am uncomfortable with returning positive values as errors, which reminds me -
I need to update the commit to mention the return 1 issue.
>
>
> > }
> > }
> >
> > @@ -422,11 +423,12 @@ static int xen_remove_from_physmap(XenIOState *state,
> > xen_pfn_t idx = start_addr + i;
> > xen_pfn_t gpfn = phys_offset + i;
> >
> > +/* In Xen 4.6 rc is -1 and errno contains the error value. */
> > rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn,
> > idx, gpfn);
> > if (rc) {
> > fprintf(stderr, "add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
> > -PRI_xen_pfn" failed: %d\n", idx, gpfn, rc);
> > -return -rc;
> > +PRI_xen_pfn" failed: %d (errno: %d)\n", idx, gpfn, rc,
> > errno);
> > +return rc == -1 ? -errno : -rc;
> > }
> > }
> >
> > --
> > 2.1.0
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] dmar: device scope mem leak fix
On Wed, Jul 01, 2015 at 11:00:45AM +0100, Andrew Cooper wrote:
> On 01/07/15 00:20, elena.ufimts...@oracle.com wrote:
> > --- a/xen/drivers/passthrough/vtd/dmar.c
> > +++ b/xen/drivers/passthrough/vtd/dmar.c
> > @@ -81,6 +81,13 @@ static int __init acpi_register_rmrr_unit(struct
> > acpi_rmrr_unit *rmrr)
> > return 0;
> > }
> >
> > +static void scope_devices_free(struct dmar_scope *scope)
> > +{
> > +if ( scope )
> > +scope->devices_cnt = 0;
> > +xfree(scope->devices);
>
> This is very liable to suffer a NULL pointer dereference.
Thanks Andrew, reposting.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 13/13] x86/altp2m: XSM hooks for altp2m HVM ops
From: Ravi Sahita
Signed-off-by: Ravi Sahita
---
tools/flask/policy/policy/modules/xen/xen.if | 4 +-
xen/arch/x86/hvm/hvm.c | 118 ---
xen/include/xsm/dummy.h | 12 +++
xen/include/xsm/xsm.h| 12 +++
xen/xsm/dummy.c | 2 +
xen/xsm/flask/hooks.c| 12 +++
xen/xsm/flask/policy/access_vectors | 7 ++
7 files changed, 119 insertions(+), 48 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.if
b/tools/flask/policy/policy/modules/xen/xen.if
index f4cde11..6177fe9 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -8,7 +8,7 @@
define(`declare_domain_common', `
allow $1 $2:grant { query setup };
allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage
updatemp mmuext_op };
- allow $1 $2:hvm { getparam setparam };
+ allow $1 $2:hvm { getparam setparam altp2mhvm_op };
allow $1 $2:domain2 get_vnumainfo;
')
@@ -58,7 +58,7 @@ define(`create_domain_common', `
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
allow $1 $2:grant setup;
allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
- setparam pcilevel trackdirtyvram nested };
+ setparam pcilevel trackdirtyvram nested altp2mhvm
altp2mhvm_op };
')
# create_domain(priv, target)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 92c123c..cc0c7b3 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5891,6 +5891,9 @@ static int hvmop_set_param(
nestedhvm_vcpu_destroy(v);
break;
case HVM_PARAM_ALTP2MHVM:
+rc = xsm_hvm_param_altp2mhvm(XSM_PRIV, d);
+if ( rc )
+break;
if ( a.value > 1 )
rc = -EINVAL;
if ( a.value &&
@@ -6471,12 +6474,15 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
if ( d == NULL )
return -ESRCH;
-rc = -EINVAL;
-if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
- d->arch.hvm_domain.params[HVM_PARAM_ALTP2MHVM] )
+if ( !(rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
{
-a.state = altp2m_active(d);
-rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
+rc = -EINVAL;
+if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
+ d->arch.hvm_domain.params[HVM_PARAM_ALTP2MHVM] )
+{
+a.state = altp2m_active(d);
+rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
+}
}
rcu_unlock_domain(d);
@@ -6497,31 +6503,34 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
if ( d == NULL )
return -ESRCH;
-rc = -EINVAL;
-if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
- d->arch.hvm_domain.params[HVM_PARAM_ALTP2MHVM] &&
- !nestedhvm_enabled(d) )
+if ( !(rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
{
-ostate = d->arch.altp2m_active;
-d->arch.altp2m_active = !!a.state;
+rc = -EINVAL;
+if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
+ d->arch.hvm_domain.params[HVM_PARAM_ALTP2MHVM] &&
+ !nestedhvm_enabled(d) )
+{
+ostate = d->arch.altp2m_active;
+d->arch.altp2m_active = !!a.state;
-rc = 0;
+rc = 0;
-/* If the alternate p2m state has changed, handle appropriately */
-if ( d->arch.altp2m_active != ostate )
-{
-if ( ostate || !(rc = p2m_init_altp2m_by_id(d, 0)) )
+/* If the alternate p2m state has changed, handle
appropriately */
+if ( d->arch.altp2m_active != ostate )
{
-for_each_vcpu( d, v )
+if ( ostate || !(rc = p2m_init_altp2m_by_id(d, 0)) )
{
-if ( !ostate )
-altp2m_vcpu_initialise(v);
-else
-altp2m_vcpu_destroy(v);
+for_each_vcpu( d, v )
+{
+if ( !ostate )
+altp2m_vcpu_initialise(v);
+else
+altp2m_vcpu_destroy(v);
+}
+
+if ( ostate )
+p2m_flush_altp2m(d);
}
-
-if ( ostate )
-p2m_flush_altp2m(d);
}
}
}
@@ -6540,6 +6549,9 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDL
[Xen-devel] [PATCH v3 12/13] x86/altp2m: Add altp2mhvm HVM domain parameter.
The altp2mhvm and nestedhvm parameters are mutually
exclusive and cannot be set together.
Signed-off-by: Ed White
---
docs/man/xl.cfg.pod.5 | 12
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_dom.c | 2 ++
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c| 8
xen/arch/x86/hvm/hvm.c | 16 +++-
xen/include/public/hvm/params.h | 5 -
7 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a3e0e2e..18afd46 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1035,6 +1035,18 @@ enabled by default and you should usually omit it. It
may be necessary
to disable the HPET in order to improve compatibility with guest
Operating Systems (X86 only)
+=item B
+
+Enables or disables hvm guest access to alternate-p2m capability.
+Alternate-p2m allows a guest to manage multiple p2m guest physical
+"memory views" (as opposed to a single p2m). This option is
+disabled by default and is available only to hvm domains.
+You may want this option if you want to access-control/isolate
+access to specific guest physical memory pages accessed by
+the guest, e.g. for HVM domain memory introspection or
+for isolation/access-control of memory between components within
+a single guest hvm domain.
+
=item B
Enable or disables guest access to hardware virtualisation features,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 86384d2..35e322e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -329,6 +329,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
+libxl_defbool_setdefault(&b_info->u.hvm.altp2mhvm, false);
libxl_defbool_setdefault(&b_info->u.hvm.usb,false);
libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 600393d..b75f49b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -300,6 +300,8 @@ static void hvm_set_conf_params(xc_interface *handle,
uint32_t domid,
libxl_defbool_val(info->u.hvm.vpt_align));
xc_hvm_param_set(handle, domid, HVM_PARAM_NESTEDHVM,
libxl_defbool_val(info->u.hvm.nested_hvm));
+xc_hvm_param_set(handle, domid, HVM_PARAM_ALTP2MHVM,
+libxl_defbool_val(info->u.hvm.altp2mhvm));
}
int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 23f27d4..66a89cf 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -437,6 +437,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("mmio_hole_memkb", MemKB),
("timer_mode", libxl_timer_mode),
("nested_hvm", libxl_defbool),
+ ("altp2mhvm",libxl_defbool),
("smbios_firmware", string),
("acpi_firmware",string),
("nographic",libxl_defbool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c858068..ccb0de9 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1500,6 +1500,14 @@ static void parse_config_data(const char *config_source,
xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
+xlu_cfg_get_defbool(config, "altp2mhvm", &b_info->u.hvm.altp2mhvm, 0);
+
+if (strcmp(libxl_defbool_to_string(b_info->u.hvm.nested_hvm), "True")
== 0 &&
+strcmp(libxl_defbool_to_string(b_info->u.hvm.altp2mhvm), "True")
== 0) {
+fprintf(stderr, "ERROR: nestedhvm and altp2mhvm cannot be used
together\n");
+exit (1);
+}
+
xlu_cfg_replace_string(config, "smbios_firmware",
&b_info->u.hvm.smbios_firmware, 0);
xlu_cfg_replace_string(config, "acpi_firmware",
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0d81050..92c123c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5754,6 +5754,7 @@ static int hvm_allow_set_param(struct domain *d,
case HVM_PARAM_VIRIDIAN:
case HVM_PARAM_IOREQ_SERVER_PFN:
case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
+case HVM_PARAM_ALTP2MHVM:
if ( value != 0 && a->value != value )
rc = -EEXIST;
break;
@@ -5876,6 +5877,9 @@ static int hvmop_set_param(
*/
if ( cpu_has_svm && !paging_mode_hap(d) && a.value )
[Xen-devel] [PATCH v3 10/13] x86/altp2m: add remaining support routines.
Add the remaining routines required to support enabling the alternate
p2m functionality.
Signed-off-by: Ed White
---
xen/arch/x86/hvm/hvm.c | 58 +-
xen/arch/x86/mm/hap/Makefile | 1 +
xen/arch/x86/mm/hap/altp2m_hap.c | 98 ++
xen/arch/x86/mm/p2m-ept.c| 3 +
xen/arch/x86/mm/p2m.c| 385 +++
xen/include/asm-x86/hvm/altp2m.h | 4 +
xen/include/asm-x86/p2m.h| 33
7 files changed, 576 insertions(+), 6 deletions(-)
create mode 100644 xen/arch/x86/mm/hap/altp2m_hap.c
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f21d34d..d2d90c8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2806,10 +2806,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long gla,
mfn_t mfn;
struct vcpu *curr = current;
struct domain *currd = curr->domain;
-struct p2m_domain *p2m;
+struct p2m_domain *p2m, *hostp2m;
int rc, fall_through = 0, paged = 0;
int sharing_enomem = 0;
vm_event_request_t *req_ptr = NULL;
+bool_t ap2m_active = 0;
/* On Nested Virtualization, walk the guest page table.
* If this succeeds, all is fine.
@@ -2869,11 +2870,31 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long gla,
goto out;
}
-p2m = p2m_get_hostp2m(currd);
-mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma,
+ap2m_active = altp2m_active(currd);
+
+/* Take a lock on the host p2m speculatively, to avoid potential
+ * locking order problems later and to handle unshare etc.
+ */
+hostp2m = p2m_get_hostp2m(currd);
+mfn = get_gfn_type_access(hostp2m, gfn, &p2mt, &p2ma,
P2M_ALLOC | (npfec.write_access ? P2M_UNSHARE :
0),
NULL);
+if ( ap2m_active )
+{
+if ( altp2m_hap_nested_page_fault(curr, gpa, gla, npfec, &p2m) == 1 )
+{
+/* entry was lazily copied from host -- retry */
+__put_gfn(hostp2m, gfn);
+rc = 1;
+goto out;
+}
+
+mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL);
+}
+else
+p2m = hostp2m;
+
/* Check access permissions first, then handle faults */
if ( mfn_x(mfn) != INVALID_MFN )
{
@@ -2913,6 +2934,20 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
if ( violation )
{
+/* Should #VE be emulated for this fault? */
+if ( p2m_is_altp2m(p2m) && !cpu_has_vmx_virt_exceptions )
+{
+bool_t sve;
+
+p2m->get_entry_full(p2m, gfn, &p2mt, &p2ma, 0, NULL, &sve);
+
+if ( !sve && ap2m_vcpu_emulate_ve(curr) )
+{
+rc = 1;
+goto out_put_gfn;
+}
+}
+
if ( p2m_mem_access_check(gpa, gla, npfec, &req_ptr) )
{
fall_through = 1;
@@ -2932,7 +2967,9 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
(npfec.write_access &&
(p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
{
-put_gfn(currd, gfn);
+__put_gfn(p2m, gfn);
+if ( ap2m_active )
+__put_gfn(hostp2m, gfn);
rc = 0;
if ( unlikely(is_pvh_domain(currd)) )
@@ -2961,6 +2998,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
/* Spurious fault? PoD and log-dirty also take this path. */
if ( p2m_is_ram(p2mt) )
{
+rc = 1;
/*
* Page log dirty is always done with order 0. If this mfn resides in
* a large page, we do not change other pages type within that large
@@ -2969,9 +3007,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
if ( npfec.write_access )
{
paging_mark_dirty(currd, mfn_x(mfn));
+/* If p2m is really an altp2m, unlock here to avoid lock ordering
+ * violation when the change below is propagated from host p2m */
+if ( ap2m_active )
+__put_gfn(p2m, gfn);
p2m_change_type_one(currd, gfn, p2m_ram_logdirty, p2m_ram_rw);
+__put_gfn(ap2m_active ? hostp2m : p2m, gfn);
+
+goto out;
}
-rc = 1;
goto out_put_gfn;
}
@@ -2981,7 +3025,9 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
rc = fall_through;
out_put_gfn:
-put_gfn(currd, gfn);
+__put_gfn(p2m, gfn);
+if ( ap2m_active )
+__put_gfn(hostp2m, gfn);
out:
/* All of these are delayed until we exit, since we might
* sleep on event ring wait queues, and we must not hold
diff --git a/xen/arch/x86/mm/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index 68f2bb5..216cd90 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -4,6 +4,7 @@ obj-y += guest_walk_3level.o
obj-$(x86_64
[Xen-devel] [PATCH v3 08/13] x86/altp2m: add control of suppress_ve.
The existing ept_set_entry() and ept_get_entry() routines are extended
to optionally set/get suppress_ve and renamed. New ept_set_entry() and
ept_get_entry() routines are provided as wrappers, where set preserves
suppress_ve for an existing entry and sets it for a new entry.
Additional function pointers are added to p2m_domain to allow direct
access to the extended routines.
Signed-off-by: Ed White
---
xen/arch/x86/mm/p2m-ept.c | 40 +---
xen/include/asm-x86/p2m.h | 13 +
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 4111795..bcb9381 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -650,14 +650,15 @@ bool_t ept_handle_misconfig(uint64_t gpa)
}
/*
- * ept_set_entry() computes 'need_modify_vtd_table' for itself,
+ * _ept_set_entry() computes 'need_modify_vtd_table' for itself,
* by observing whether any gfn->mfn translations are modified.
*
* Returns: 0 for success, -errno for failure
*/
static int
-ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
- unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+_ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+ unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
+ int sve)
{
ept_entry_t *table, *ept_entry = NULL;
unsigned long gfn_remainder = gfn;
@@ -803,7 +804,11 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn,
mfn_t mfn,
ept_p2m_type_to_flags(p2m, &new_entry, p2mt, p2ma);
}
-new_entry.suppress_ve = 1;
+if ( sve != -1 )
+new_entry.suppress_ve = !!sve;
+else
+new_entry.suppress_ve = is_epte_valid(&old_entry) ?
+old_entry.suppress_ve : 1;
rc = atomic_write_ept_entry(ept_entry, new_entry, target);
if ( unlikely(rc) )
@@ -848,10 +853,18 @@ out:
return rc;
}
+static int
+ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
+ unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma)
+{
+return _ept_set_entry(p2m, gfn, mfn, order, p2mt, p2ma, -1);
+}
+
/* Read ept p2m entries */
-static mfn_t ept_get_entry(struct p2m_domain *p2m,
- unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
- p2m_query_t q, unsigned int *page_order)
+static mfn_t _ept_get_entry(struct p2m_domain *p2m,
+unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
+p2m_query_t q, unsigned int *page_order,
+bool_t *sve)
{
ept_entry_t *table =
map_domain_page(pagetable_get_pfn(p2m_get_pagetable(p2m)));
unsigned long gfn_remainder = gfn;
@@ -865,6 +878,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
*t = p2m_mmio_dm;
*a = p2m_access_n;
+if ( sve )
+*sve = 1;
/* This pfn is higher than the highest the p2m map currently holds */
if ( gfn > p2m->max_mapped_pfn )
@@ -930,6 +945,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
else
*t = ept_entry->sa_p2mt;
*a = ept_entry->access;
+if ( sve )
+*sve = ept_entry->suppress_ve;
mfn = _mfn(ept_entry->mfn);
if ( i )
@@ -953,6 +970,13 @@ out:
return mfn;
}
+static mfn_t ept_get_entry(struct p2m_domain *p2m,
+ unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
+ p2m_query_t q, unsigned int *page_order)
+{
+return _ept_get_entry(p2m, gfn, t, a, q, page_order, NULL);
+}
+
void ept_walk_table(struct domain *d, unsigned long gfn)
{
struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1131,6 +1155,8 @@ int ept_p2m_init(struct p2m_domain *p2m)
p2m->set_entry = ept_set_entry;
p2m->get_entry = ept_get_entry;
+p2m->set_entry_full = _ept_set_entry;
+p2m->get_entry_full = _ept_get_entry;
p2m->change_entry_type_global = ept_change_entry_type_global;
p2m->change_entry_type_range = ept_change_entry_type_range;
p2m->memory_type_changed = ept_memory_type_changed;
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 079a298..bf5e5cb 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -237,6 +237,19 @@ struct p2m_domain {
p2m_access_t *p2ma,
p2m_query_t q,
unsigned int *page_order);
+int(*set_entry_full)(struct p2m_domain *p2m,
+ unsigned long gfn,
+ mfn_t mfn, unsigned int page_order,
+ p2m_type_t p2mt,
+ p2m_access_t p2ma,
+ int sve);
+mfn_t
[Xen-devel] [PATCH v3 09/13] x86/altp2m: alternate p2m memory events.
Add a flag to indicate that a memory event occurred in an alternate p2m
and a field containing the p2m index. Allow any event response to switch
to a different alternate p2m using the same flag and field.
Modify p2m_memory_access_check() to handle alternate p2m's.
Signed-off-by: Ed White
---
xen/arch/x86/mm/p2m.c | 20 +++-
xen/common/vm_event.c | 3 +++
xen/include/asm-arm/p2m.h | 6 ++
xen/include/asm-x86/p2m.h | 3 +++
xen/include/public/vm_event.h | 11 +++
5 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 58d4951..576b28d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1514,6 +1514,13 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
}
}
+void p2m_altp2m_check(struct vcpu *v, const vm_event_response_t *rsp)
+{
+if ( (rsp->flags & VM_EVENT_FLAG_ALTERNATE_P2M) &&
+ altp2m_active(v->domain) )
+p2m_switch_vcpu_altp2m_by_id(v, rsp->altp2m_idx);
+}
+
bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
struct npfec npfec,
vm_event_request_t **req_ptr)
@@ -1521,7 +1528,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long
gla,
struct vcpu *v = current;
unsigned long gfn = gpa >> PAGE_SHIFT;
struct domain *d = v->domain;
-struct p2m_domain* p2m = p2m_get_hostp2m(d);
+struct p2m_domain *p2m = NULL;
mfn_t mfn;
p2m_type_t p2mt;
p2m_access_t p2ma;
@@ -1529,6 +1536,11 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long
gla,
int rc;
unsigned long eip = guest_cpu_user_regs()->eip;
+if ( altp2m_active(d) )
+p2m = p2m_get_altp2m(v);
+if ( !p2m )
+p2m = p2m_get_hostp2m(d);
+
/* First, handle rx2rw conversion automatically.
* These calls to p2m->set_entry() must succeed: we have the gfn
* locked and just did a successful get_entry(). */
@@ -1635,6 +1647,12 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long
gla,
req->vcpu_id = v->vcpu_id;
p2m_vm_event_fill_regs(req);
+
+if ( altp2m_active(v->domain) )
+{
+req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
+req->altp2m_idx = vcpu_altp2m(v).p2midx;
+}
}
/* Pause the current VCPU */
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 120a78a..57095d8 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -399,6 +399,9 @@ void vm_event_resume(struct domain *d, struct
vm_event_domain *ved)
};
+/* Check for altp2m switch */
+p2m_altp2m_check(v, &rsp);
+
/* Unpause domain. */
if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
vm_event_vcpu_unpause(v);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 63748ef..3206c75 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -109,6 +109,12 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
/* Not supported on ARM. */
}
+static inline
+void p2m_altp2m_check(struct vcpu *v, const vm_event_response_t *rsp)
+{
+/* Not supported on ARM. */
+}
+
#define p2m_is_foreign(_t) ((_t) == p2m_map_foreign)
#define p2m_is_ram(_t) ((_t) == p2m_ram_rw || (_t) == p2m_ram_ro)
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index bf5e5cb..5689f40 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -762,6 +762,9 @@ uint16_t p2m_find_altp2m_by_eptp(struct domain *d, uint64_t
eptp);
/* Switch alternate p2m for a single vcpu */
bool_t p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, uint16_t idx);
+/* Check to see if vcpu should be switched to a different p2m. */
+void p2m_altp2m_check(struct vcpu *v, const vm_event_response_t *rsp);
+
/*
* p2m type to IOMMU flags
*/
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 577e971..6dfa9db 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -47,6 +47,16 @@
#define VM_EVENT_FLAG_VCPU_PAUSED (1 << 0)
/* Flags to aid debugging mem_event */
#define VM_EVENT_FLAG_FOREIGN (1 << 1)
+/*
+ * This flag can be set in a request or a response
+ *
+ * On a request, indicates that the event occurred in the alternate p2m
specified by
+ * the altp2m_idx request field.
+ *
+ * On a response, indicates that the VCPU should resume in the alternate p2m
specified
+ * by the altp2m_idx response field if possible.
+ */
+#define VM_EVENT_FLAG_ALTERNATE_P2M (1 << 2)
/*
* Reasons for the vm event request
@@ -194,6 +204,7 @@ typedef struct vm_event_st {
uint32_t flags; /* VM_EVENT_FLAG_* */
uint32_t reason;/* VM_EVENT_REASON_* */
uint32_t vcpu_id;
+uint16_t altp2m_idx; /* may be used during request and response */
union {
struct vm_event_pagingmem_paging;
--
1.9.1
___
[Xen-devel] [PATCH v3 11/13] x86/altp2m: define and implement alternate p2m HVMOP types.
Signed-off-by: Ed White
---
xen/arch/x86/hvm/hvm.c | 201
xen/include/public/hvm/hvm_op.h | 69 ++
2 files changed, 270 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d2d90c8..0d81050 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6447,6 +6447,207 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
}
+case HVMOP_altp2m_get_domain_state:
+{
+struct xen_hvm_altp2m_domain_state a;
+struct domain *d;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = -EINVAL;
+if ( is_hvm_domain(d) && hvm_altp2m_supported() )
+{
+a.state = altp2m_active(d);
+rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
+}
+
+rcu_unlock_domain(d);
+break;
+}
+
+case HVMOP_altp2m_set_domain_state:
+{
+struct xen_hvm_altp2m_domain_state a;
+struct domain *d;
+struct vcpu *v;
+bool_t ostate;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = -EINVAL;
+if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
+ !nestedhvm_enabled(d) )
+{
+ostate = d->arch.altp2m_active;
+d->arch.altp2m_active = !!a.state;
+
+rc = 0;
+
+/* If the alternate p2m state has changed, handle appropriately */
+if ( d->arch.altp2m_active != ostate )
+{
+if ( ostate || !(rc = p2m_init_altp2m_by_id(d, 0)) )
+{
+for_each_vcpu( d, v )
+{
+if ( !ostate )
+altp2m_vcpu_initialise(v);
+else
+altp2m_vcpu_destroy(v);
+}
+
+if ( ostate )
+p2m_flush_altp2m(d);
+}
+}
+}
+
+rcu_unlock_domain(d);
+break;
+}
+
+case HVMOP_altp2m_vcpu_enable_notify:
+{
+struct domain *curr_d = current->domain;
+struct vcpu *curr = current;
+struct xen_hvm_altp2m_vcpu_enable_notify a;
+p2m_type_t p2mt;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+if ( !is_hvm_domain(curr_d) || !hvm_altp2m_supported() ||
+ !curr_d->arch.altp2m_active ||
+ gfn_x(vcpu_altp2m(curr).veinfo_gfn) != INVALID_GFN)
+return -EINVAL;
+
+if ( mfn_x(get_gfn_query_unlocked(curr_d, a.gfn, &p2mt)) ==
+ INVALID_MFN )
+return -EINVAL;
+
+vcpu_altp2m(curr).veinfo_gfn = _gfn(a.gfn);
+ap2m_vcpu_update_vmfunc_ve(curr);
+rc = 0;
+
+break;
+}
+
+case HVMOP_altp2m_create_p2m:
+{
+struct xen_hvm_altp2m_view a;
+struct domain *d;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = -EINVAL;
+if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
+ d->arch.altp2m_active &&
+ !(rc = p2m_init_next_altp2m(d, &a.view)) )
+rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
+
+rcu_unlock_domain(d);
+break;
+}
+
+case HVMOP_altp2m_destroy_p2m:
+{
+struct xen_hvm_altp2m_view a;
+struct domain *d;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = -EINVAL;
+if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
+ d->arch.altp2m_active )
+rc = p2m_destroy_altp2m_by_id(d, a.view);
+
+rcu_unlock_domain(d);
+break;
+}
+
+case HVMOP_altp2m_switch_p2m:
+{
+struct xen_hvm_altp2m_view a;
+struct domain *d;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = -EINVAL;
+if ( is_hvm_domain(d) && hvm_altp2m_supported() &&
+ d->arch.altp2m_active )
+rc = p2m_switch_domain_altp2m_by_id(d, a.view);
+
+rcu_unlock_domain(d);
+break;
+}
+
+case HVMOP_altp2m_set_mem_access:
+{
+struct xen_hvm_altp2m_set_mem_access a;
+struct domain *d;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+i
[Xen-devel] [PATCH v3 03/13] VMX: implement suppress #VE.
In preparation for selectively enabling #VE in a later patch, set
suppress #VE on all EPTE's.
Suppress #VE should always be the default condition for two reasons:
it is generally not safe to deliver #VE into a guest unless that guest
has been modified to receive it; and even then for most EPT violations only
the hypervisor is able to handle the violation.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
---
xen/arch/x86/mm/p2m-ept.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index a6c9adf..4111795 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -41,7 +41,8 @@
#define is_epte_superpage(ept_entry)((ept_entry)->sp)
static inline bool_t is_epte_valid(ept_entry_t *e)
{
-return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
+/* suppress_ve alone is not considered valid, so mask it off */
+return ((e->epte & ~(1ul << 63)) != 0 && e->sa_p2mt != p2m_invalid);
}
/* returns : 0 for success, -errno otherwise */
@@ -219,6 +220,8 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m,
ept_entry_t *entry,
static int ept_set_middle_entry(struct p2m_domain *p2m, ept_entry_t *ept_entry)
{
struct page_info *pg;
+ept_entry_t *table;
+unsigned int i;
pg = p2m_alloc_ptp(p2m, 0);
if ( pg == NULL )
@@ -232,6 +235,15 @@ static int ept_set_middle_entry(struct p2m_domain *p2m,
ept_entry_t *ept_entry)
/* Manually set A bit to avoid overhead of MMU having to write it later. */
ept_entry->a = 1;
+ept_entry->suppress_ve = 1;
+
+table = __map_domain_page(pg);
+
+for ( i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
+table[i].suppress_ve = 1;
+
+unmap_domain_page(table);
+
return 1;
}
@@ -281,6 +293,7 @@ static int ept_split_super_page(struct p2m_domain *p2m,
ept_entry_t *ept_entry,
epte->sp = (level > 1);
epte->mfn += i * trunk;
epte->snp = (iommu_enabled && iommu_snoop);
+epte->suppress_ve = 1;
ept_p2m_type_to_flags(p2m, epte, epte->sa_p2mt, epte->access);
@@ -790,6 +803,8 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn,
mfn_t mfn,
ept_p2m_type_to_flags(p2m, &new_entry, p2mt, p2ma);
}
+new_entry.suppress_ve = 1;
+
rc = atomic_write_ept_entry(ept_entry, new_entry, target);
if ( unlikely(rc) )
old_entry.epte = 0;
@@ -,6 +1126,8 @@ static void ept_flush_pml_buffers(struct p2m_domain *p2m)
int ept_p2m_init(struct p2m_domain *p2m)
{
struct ept_data *ept = &p2m->ept;
+ept_entry_t *table;
+unsigned int i;
p2m->set_entry = ept_set_entry;
p2m->get_entry = ept_get_entry;
@@ -1134,6 +1151,13 @@ int ept_p2m_init(struct p2m_domain *p2m)
p2m->flush_hardware_cached_dirty = ept_flush_pml_buffers;
}
+table = map_domain_page(pagetable_get_pfn(p2m_get_pagetable(p2m)));
+
+for ( i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
+table[i].suppress_ve = 1;
+
+unmap_domain_page(table);
+
if ( !zalloc_cpumask_var(&ept->synced_mask) )
return -ENOMEM;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m
This set of patches adds support to hvm domains for EPTP switching by creating multiple copies of the host p2m (currently limited to 10 copies). The primary use of this capability is expected to be in scenarios where access to memory needs to be monitored and/or restricted below the level at which the guest OS page tables operate. Two examples that were discussed at the 2014 Xen developer summit are: VM introspection: http://www.slideshare.net/xen_com_mgr/ zero-footprint-guest-memory-introspection-from-xen Secure inter-VM communication: http://www.slideshare.net/xen_com_mgr/nakajima-nvf A more detailed design specification can be found at: http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01319.html Each p2m copy is populated lazily on EPT violations. Permissions for pages in alternate p2m's can be changed in a similar way to the existing memory access interface, and gfn->mfn mappings can be changed. All this is done through extra HVMOP types. The cross-domain HVMOP code has been compile-tested only. Also, the cross-domain code is hypervisor-only, the toolstack has not been modified. The intra-domain code has been tested. Violation notifications can only be received for pages that have been modified (access permissions and/or gfn->mfn mapping) intra-domain, and only on VCPU's that have enabled notification. VMFUNC and #VE will both be emulated on hardware without native support. This code is not compatible with nested hvm functionality and will refuse to work with nested hvm active. It is also not compatible with migration. It should be considered experimental. Changes since v2: Addressed all v2 feedback *except*: In patch 5, the per-domain EPTP list page is still allocated from the Xen heap. If allocated from the domain heap Xen panics - IIRC on Haswell hardware when walking the EPTP list during exit processing in patch 6. HVM_ops are not merged. Tamas suggested merging the memory access ops, but in practice they are not as similar as they appear on the surface. Razvan suggested merging the implementation code in p2m.c, but that is also not as common as it appears on the surface. Andrew suggested merging all altp2m ops into one with a subop code in the input stucture. His point that only 255 ops can be defined is well taken, but altp2m uses only 2 more ops than the recently introduced ioreq ops, and <15% of the available ops have been defined. Since we don't know how to implement XSM hooks and policy with the subop model, we have not adopted this suggestion. The p2m set/get interface is not modified. The altp2m code needs to write suppress_ve in 2 places and read it in 1 place. The original patch series managed this by coupling the state of suppress_ve to the p2m memory type, which Tim disliked. In v2 of the series, special set/get interaces were added to access suppress_ve only when required. Jan has suggested changing the existing interfaces, but we feel this is inappropriate for this experimental patch series. Changing the existing interfaces would require a design agreement to be reached and would impact a large amount of existing code. Andrew kindly added some reviewed-by's to v2. I have not carried his reviewed-by of the memory event patch forward because Tamas requested significant changes to the patch. Changes since v1: Many changes since v1 in response to maintainer feedback, including: Suppress_ve state is now decoupled from memory type VMFUNC emulation handled in x86 emulator Lazy-copy algorithm copies any page where mfn != INVALID_MFN All nested page fault handling except lazy-copy is now in top-level (hvm.c) nested page fault handler Split p2m lock type (as suggested by Tim) to avoid lock order violations XSM hooks Xen parameter to globally enable altp2m (default disabled) and HVM parameter Altp2m reference counting no longer uses dirty_cpu bitmap Remapped page tracking to invalidate altp2m's where needed to protect Xen Many other minor changes The altp2m invalidation is implemented to a level that I believe satisifies the requirements of protecting Xen. Invalidation notification is not yet implemented, and there may be other cases where invalidation is warranted to protect the integrity of the restrictions placed through altp2m. We may add further patches in this area. Testability is still a potential issue. We have offered to make our internal Windows test binaries available for intra-domain testing. Tamas has been working on toolstack support for cross-domain testing with a slightly earlier patch series, and we hope he will submit that support. Not all of the patches will be of interest to everyone copied here. I've copied everyone on this initial mailing to give context. Andrew Cooper (1): common/domain: Helpers to pause a domain while in context Ed White (10)
[Xen-devel] [PATCH v3 05/13] x86/altp2m: basic data structures and support routines.
Add the basic data structures needed to support alternate p2m's and
the functions to initialise them and tear them down.
Although Intel hardware can handle 512 EPTP's per hardware thread
concurrently, only 10 per domain are supported in this patch for
performance reasons.
The iterator in hap_enable() does need to handle 512, so that is now
uint16_t.
This change also splits the p2m lock into one lock type for altp2m's
and another type for all other p2m's. The purpose of this is to place
the altp2m list lock between the types, so the list lock can be
acquired whilst holding the host p2m lock.
Signed-off-by: Ed White
---
xen/arch/x86/hvm/Makefile| 1 +
xen/arch/x86/hvm/altp2m.c| 92 +
xen/arch/x86/hvm/hvm.c | 21 +
xen/arch/x86/mm/hap/hap.c| 31 -
xen/arch/x86/mm/mm-locks.h | 38 +++-
xen/arch/x86/mm/p2m.c| 98
xen/include/asm-x86/domain.h | 10
xen/include/asm-x86/hvm/altp2m.h | 38
xen/include/asm-x86/hvm/hvm.h| 17 +++
xen/include/asm-x86/hvm/vcpu.h | 9
xen/include/asm-x86/p2m.h| 30 +++-
11 files changed, 381 insertions(+), 4 deletions(-)
create mode 100644 xen/arch/x86/hvm/altp2m.c
create mode 100644 xen/include/asm-x86/hvm/altp2m.h
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 69af47f..eb1a37b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -1,6 +1,7 @@
subdir-y += svm
subdir-y += vmx
+obj-y += altp2m.o
obj-y += asid.o
obj-y += emulate.o
obj-y += event.o
diff --git a/xen/arch/x86/hvm/altp2m.c b/xen/arch/x86/hvm/altp2m.c
new file mode 100644
index 000..f98a38d
--- /dev/null
+++ b/xen/arch/x86/hvm/altp2m.c
@@ -0,0 +1,92 @@
+/*
+ * Alternate p2m HVM
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include
+#include
+#include
+#include
+
+void
+altp2m_vcpu_reset(struct vcpu *v)
+{
+struct altp2mvcpu *av = &vcpu_altp2m(v);
+
+av->p2midx = INVALID_ALTP2M;
+av->veinfo_gfn = _gfn(INVALID_GFN);
+
+if ( hvm_funcs.ap2m_vcpu_reset )
+hvm_funcs.ap2m_vcpu_reset(v);
+}
+
+int
+altp2m_vcpu_initialise(struct vcpu *v)
+{
+int rc = -EOPNOTSUPP;
+
+if ( v != current )
+vcpu_pause(v);
+
+if ( !hvm_funcs.ap2m_vcpu_initialise ||
+ (hvm_funcs.ap2m_vcpu_initialise(v) == 0) )
+{
+rc = 0;
+altp2m_vcpu_reset(v);
+vcpu_altp2m(v).p2midx = 0;
+atomic_inc(&p2m_get_altp2m(v)->active_vcpus);
+
+ap2m_vcpu_update_eptp(v);
+}
+
+if ( v != current )
+vcpu_unpause(v);
+
+return rc;
+}
+
+void
+altp2m_vcpu_destroy(struct vcpu *v)
+{
+struct p2m_domain *p2m;
+
+if ( v != current )
+vcpu_pause(v);
+
+if ( hvm_funcs.ap2m_vcpu_destroy )
+hvm_funcs.ap2m_vcpu_destroy(v);
+
+if ( (p2m = p2m_get_altp2m(v)) )
+atomic_dec(&p2m->active_vcpus);
+
+altp2m_vcpu_reset(v);
+
+ap2m_vcpu_update_eptp(v);
+ap2m_vcpu_update_vmfunc_ve(v);
+
+if ( v != current )
+vcpu_unpause(v);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6faf3f4..f21d34d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -58,6 +58,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2380,6 +2381,7 @@ void hvm_vcpu_destroy(struct vcpu *v)
{
hvm_all_ioreq_servers_remove_vcpu(v->domain, v);
+altp2m_vcpu_destroy(v);
nestedhvm_vcpu_destroy(v);
free_compat_arg_xlat(v);
@@ -6502,6 +6504,25 @@ enum hvm_intblk nhvm_interrupt_blocked(struct vcpu *v)
return hvm_funcs.nhvm_intr_blocked(v);
}
+void ap2m_vcpu_update_eptp(struct vcpu *v)
+{
+if (hvm_funcs.ap2m_vcpu_update_eptp)
+hvm_funcs.ap2m_vcpu_update_eptp(v);
+}
+
+void ap2m_vcpu_update_vmfunc_ve(struct vcpu *v)
+{
+if (hvm_funcs.ap2m_vcpu_update_vmfunc_ve)
+hvm_funcs.ap2m_vcpu_update_vmfunc_ve(v);
+}
+
+bool_t ap2m_vcpu_emulate_ve(struct vcpu *v)
+{
+if (hvm_funcs.ap2m_vcpu_emulate_ve)
+return hvm_funcs.ap2m_vcpu_emulate_ve(v);
+return
[Xen-devel] [PATCH v3 07/13] VMX: add VMFUNC leaf 0 (EPTP switching) to emulator.
From: Ravi Sahita
Signed-off-by: Ravi Sahita
---
xen/arch/x86/hvm/emulate.c | 12 +++--
xen/arch/x86/hvm/vmx/vmx.c | 30 +
xen/arch/x86/x86_emulate/x86_emulate.c | 48 +-
xen/arch/x86/x86_emulate/x86_emulate.h | 4 +++
xen/include/asm-x86/hvm/hvm.h | 2 ++
5 files changed, 76 insertions(+), 20 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index ac9c9d6..157fe78 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1356,6 +1356,12 @@ static int hvmemul_invlpg(
return rc;
}
+static int hvmemul_vmfunc(
+struct x86_emulate_ctxt *ctxt)
+{
+return hvm_funcs.ap2m_vcpu_emulate_vmfunc(ctxt->regs);
+}
+
static const struct x86_emulate_ops hvm_emulate_ops = {
.read = hvmemul_read,
.insn_fetch= hvmemul_insn_fetch,
@@ -1379,7 +1385,8 @@ static const struct x86_emulate_ops hvm_emulate_ops = {
.inject_sw_interrupt = hvmemul_inject_sw_interrupt,
.get_fpu = hvmemul_get_fpu,
.put_fpu = hvmemul_put_fpu,
-.invlpg= hvmemul_invlpg
+.invlpg= hvmemul_invlpg,
+.vmfunc= hvmemul_vmfunc,
};
static const struct x86_emulate_ops hvm_emulate_ops_no_write = {
@@ -1405,7 +1412,8 @@ static const struct x86_emulate_ops
hvm_emulate_ops_no_write = {
.inject_sw_interrupt = hvmemul_inject_sw_interrupt,
.get_fpu = hvmemul_get_fpu,
.put_fpu = hvmemul_put_fpu,
-.invlpg= hvmemul_invlpg
+.invlpg= hvmemul_invlpg,
+.vmfunc= hvmemul_vmfunc,
};
static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9585aa3..c6feeae 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -82,6 +82,7 @@ static void vmx_fpu_dirty_intercept(void);
static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content);
static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content);
static void vmx_invlpg_intercept(unsigned long vaddr);
+static int vmx_vmfunc_intercept(struct cpu_user_regs *regs);
uint8_t __read_mostly posted_intr_vector;
@@ -1830,6 +1831,20 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
vmx_vmcs_exit(v);
}
+static int vmx_vcpu_emulate_vmfunc(struct cpu_user_regs *regs)
+{
+int rc = X86EMUL_EXCEPTION;
+struct vcpu *v = current;
+
+if ( !cpu_has_vmx_vmfunc && altp2m_active(v->domain) &&
+ regs->eax == 0 &&
+ p2m_switch_vcpu_altp2m_by_id(v, (uint16_t)regs->ecx) )
+{
+rc = X86EMUL_OKAY;
+}
+return rc;
+}
+
static bool_t vmx_vcpu_emulate_ve(struct vcpu *v)
{
bool_t rc = 0;
@@ -1898,6 +1913,7 @@ static struct hvm_function_table __initdata
vmx_function_table = {
.msr_read_intercept = vmx_msr_read_intercept,
.msr_write_intercept = vmx_msr_write_intercept,
.invlpg_intercept = vmx_invlpg_intercept,
+.vmfunc_intercept = vmx_vmfunc_intercept,
.handle_cd= vmx_handle_cd,
.set_info_guest = vmx_set_info_guest,
.set_rdtsc_exiting= vmx_set_rdtsc_exiting,
@@ -1924,6 +1940,7 @@ static struct hvm_function_table __initdata
vmx_function_table = {
.ap2m_vcpu_update_eptp = vmx_vcpu_update_eptp,
.ap2m_vcpu_update_vmfunc_ve = vmx_vcpu_update_vmfunc_ve,
.ap2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve,
+.ap2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
};
const struct hvm_function_table * __init start_vmx(void)
@@ -2095,6 +2112,12 @@ static void vmx_invlpg_intercept(unsigned long vaddr)
vpid_sync_vcpu_gva(curr, vaddr);
}
+static int vmx_vmfunc_intercept(struct cpu_user_regs *regs)
+{
+gdprintk(XENLOG_ERR, "Failed guest VMFUNC execution\n");
+return X86EMUL_EXCEPTION;
+}
+
static int vmx_cr_access(unsigned long exit_qualification)
{
struct vcpu *curr = current;
@@ -3245,6 +3268,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
update_guest_eip();
break;
+case EXIT_REASON_VMFUNC:
+if ( vmx_vmfunc_intercept(regs) == X86EMUL_OKAY )
+update_guest_eip();
+else
+hvm_inject_hw_exception(TRAP_invalid_op,
HVM_DELIVER_NO_ERROR_CODE);
+break;
+
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
case EXIT_REASON_GETSEC:
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index c017c69..adf64d0 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3815,28 +3815,40 @@ x86_emulate(
case 0x01: /* Grp7 */ {
struct segment_register reg;
unsigned long base, limit, cr0, cr0w;
+uint64_t tsc_aux;
-if ( modrm == 0xdf ) /* invlpga */
+switch( modrm )
{
-generate_exception_if(!in_protmode(ctxt, op
[Xen-devel] [PATCH v3 06/13] VMX/altp2m: add code to support EPTP switching and #VE.
Implement and hook up the code to enable VMX support of VMFUNC and #VE.
VMFUNC leaf 0 (EPTP switching) emulation is added in a later patch.
Signed-off-by: Ed White
---
xen/arch/x86/hvm/vmx/vmx.c | 138 +
1 file changed, 138 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2d3ad63..9585aa3 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1763,6 +1764,104 @@ static void vmx_enable_msr_exit_interception(struct
domain *d)
MSR_TYPE_W);
}
+static void vmx_vcpu_update_eptp(struct vcpu *v)
+{
+struct domain *d = v->domain;
+struct p2m_domain *p2m = NULL;
+struct ept_data *ept;
+
+if ( altp2m_active(d) )
+p2m = p2m_get_altp2m(v);
+if ( !p2m )
+p2m = p2m_get_hostp2m(d);
+
+ept = &p2m->ept;
+ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
+
+vmx_vmcs_enter(v);
+
+__vmwrite(EPT_POINTER, ept_get_eptp(ept));
+
+if ( v->arch.hvm_vmx.secondary_exec_control &
+SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS )
+__vmwrite(EPTP_INDEX, vcpu_altp2m(v).p2midx);
+
+vmx_vmcs_exit(v);
+}
+
+static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
+{
+struct domain *d = v->domain;
+u32 mask = SECONDARY_EXEC_ENABLE_VM_FUNCTIONS;
+
+if ( !cpu_has_vmx_vmfunc )
+return;
+
+if ( cpu_has_vmx_virt_exceptions )
+mask |= SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
+
+vmx_vmcs_enter(v);
+
+if ( !d->is_dying && altp2m_active(d) )
+{
+v->arch.hvm_vmx.secondary_exec_control |= mask;
+__vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
+__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
+
+if ( cpu_has_vmx_virt_exceptions )
+{
+p2m_type_t t;
+mfn_t mfn;
+
+mfn = get_gfn_query_unlocked(d, gfn_x(vcpu_altp2m(v).veinfo_gfn),
&t);
+
+if ( mfn_x(mfn) != INVALID_MFN )
+__vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT);
+else
+mask &= ~SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
+}
+}
+else
+v->arch.hvm_vmx.secondary_exec_control &= ~mask;
+
+__vmwrite(SECONDARY_VM_EXEC_CONTROL,
+v->arch.hvm_vmx.secondary_exec_control);
+
+vmx_vmcs_exit(v);
+}
+
+static bool_t vmx_vcpu_emulate_ve(struct vcpu *v)
+{
+bool_t rc = 0;
+ve_info_t *veinfo = gfn_x(vcpu_altp2m(v).veinfo_gfn) != INVALID_GFN ?
+hvm_map_guest_frame_rw(gfn_x(vcpu_altp2m(v).veinfo_gfn), 0) : NULL;
+
+if ( !veinfo )
+return 0;
+
+if ( veinfo->semaphore != 0 )
+goto out;
+
+rc = 1;
+
+veinfo->exit_reason = EXIT_REASON_EPT_VIOLATION;
+veinfo->semaphore = ~0l;
+veinfo->eptp_index = vcpu_altp2m(v).p2midx;
+
+vmx_vmcs_enter(v);
+__vmread(EXIT_QUALIFICATION, &veinfo->exit_qualification);
+__vmread(GUEST_LINEAR_ADDRESS, &veinfo->gla);
+__vmread(GUEST_PHYSICAL_ADDRESS, &veinfo->gpa);
+vmx_vmcs_exit(v);
+
+hvm_inject_hw_exception(TRAP_virtualisation,
+HVM_DELIVER_NO_ERROR_CODE);
+
+out:
+hvm_unmap_guest_frame(veinfo, 0);
+return rc;
+}
+
static struct hvm_function_table __initdata vmx_function_table = {
.name = "VMX",
.cpu_up_prepare = vmx_cpu_up_prepare,
@@ -1822,6 +1921,9 @@ static struct hvm_function_table __initdata
vmx_function_table = {
.nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m,
.hypervisor_cpuid_leaf = vmx_hypervisor_cpuid_leaf,
.enable_msr_exit_interception = vmx_enable_msr_exit_interception,
+.ap2m_vcpu_update_eptp = vmx_vcpu_update_eptp,
+.ap2m_vcpu_update_vmfunc_ve = vmx_vcpu_update_vmfunc_ve,
+.ap2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve,
};
const struct hvm_function_table * __init start_vmx(void)
@@ -2754,6 +2856,42 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
/* Now enable interrupts so it's safe to take locks. */
local_irq_enable();
+
+/*
+ * If the guest has the ability to switch EPTP without an exit,
+ * figure out whether it has done so and update the altp2m data.
+ */
+if ( altp2m_active(v->domain) &&
+(v->arch.hvm_vmx.secondary_exec_control &
+SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) )
+{
+unsigned long idx;
+
+if ( v->arch.hvm_vmx.secondary_exec_control &
+SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS )
+__vmread(EPTP_INDEX, &idx);
+else
+{
+unsigned long eptp;
+
+__vmread(EPT_POINTER, &eptp);
+
+if ( (idx = p2m_find_altp2m_by_eptp(v->domain, eptp)) ==
+ INVALID_ALTP2M )
+{
+gdprintk(XENLOG_ERR, "EPTP not found in alternate p2m list\n");
+domain_crash(v->domain);
[Xen-devel] [PATCH v3 01/13] common/domain: Helpers to pause a domain while in context
From: Andrew Cooper
For use on codepaths which would need to use domain_pause() but might be in
the target domain's context. In the case that the target domain is in
context, all other vcpus are paused.
Signed-off-by: Andrew Cooper
---
xen/common/domain.c | 28
xen/include/xen/sched.h | 5 +
2 files changed, 33 insertions(+)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 3bc52e6..1bb24ae 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1010,6 +1010,34 @@ int domain_unpause_by_systemcontroller(struct domain *d)
return 0;
}
+void domain_pause_except_self(struct domain *d)
+{
+struct vcpu *v, *curr = current;
+
+if ( curr->domain == d )
+{
+for_each_vcpu( d, v )
+if ( likely(v != curr) )
+vcpu_pause(v);
+}
+else
+domain_pause(d);
+}
+
+void domain_unpause_except_self(struct domain *d)
+{
+struct vcpu *v, *curr = current;
+
+if ( curr->domain == d )
+{
+for_each_vcpu( d, v )
+if ( likely(v != curr) )
+vcpu_unpause(v);
+}
+else
+domain_unpause(d);
+}
+
int vcpu_reset(struct vcpu *v)
{
struct domain *d = v->domain;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index d810e1c..e68a860 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -803,6 +803,11 @@ static inline int
domain_pause_by_systemcontroller_nosync(struct domain *d)
{
return __domain_pause_by_systemcontroller(d, domain_pause_nosync);
}
+
+/* domain_pause() but safe against trying to pause current. */
+void domain_pause_except_self(struct domain *d);
+void domain_unpause_except_self(struct domain *d);
+
void cpu_init(void);
struct scheduler;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 04/13] x86/HVM: Hardware alternate p2m support detection.
As implemented here, only supported on platforms with VMX HAP.
By default this functionality is force-disabled, it can be enabled
by specifying altp2m=1 on the Xen command line.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
---
docs/misc/xen-command-line.markdown | 7 +++
xen/arch/x86/hvm/hvm.c | 7 +++
xen/arch/x86/hvm/vmx/vmx.c | 1 +
xen/include/asm-x86/hvm/hvm.h | 9 +
4 files changed, 24 insertions(+)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index aa684c0..3391c66 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -139,6 +139,13 @@ mode during S3 resume.
> Default: `true`
Permit Xen to use superpages when performing memory management.
+
+### altp2m (Intel)
+> `= `
+
++> Default: `false`
+
+Permit multiple copies of host p2m.
### apic
> `= bigsmp | default`
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d5e5242..6faf3f4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -94,6 +94,10 @@ bool_t opt_hvm_fep;
boolean_param("hvm_fep", opt_hvm_fep);
#endif
+/* Xen command-line option to enable altp2m */
+static bool_t __initdata opt_altp2m_enabled = 0;
+boolean_param("altp2m", opt_altp2m_enabled);
+
static int cpu_callback(
struct notifier_block *nfb, unsigned long action, void *hcpu)
{
@@ -160,6 +164,9 @@ static int __init hvm_enable(void)
if ( !fns->pvh_supported )
printk(XENLOG_INFO "HVM: PVH mode not supported on this platform\n");
+if ( !opt_altp2m_enabled )
+hvm_funcs.altp2m_supported = 0;
+
/*
* Allow direct access to the PC debug ports 0x80 and 0xed (they are
* often used for I/O delays, but the vmexits simply slow things down).
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0837627..2d3ad63 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1841,6 +1841,7 @@ const struct hvm_function_table * __init start_vmx(void)
if ( cpu_has_vmx_ept && (cpu_has_vmx_pat || opt_force_ept) )
{
vmx_function_table.hap_supported = 1;
+vmx_function_table.altp2m_supported = 1;
vmx_function_table.hap_capabilities = 0;
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 77eeac5..8aa2bb3 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -94,6 +94,9 @@ struct hvm_function_table {
/* Necessary hardware support for PVH mode? */
int pvh_supported;
+/* Necessary hardware support for alternate p2m's? */
+bool_t altp2m_supported;
+
/* Indicate HAP capabilities. */
int hap_capabilities;
@@ -509,6 +512,12 @@ bool_t nhvm_vmcx_hap_enabled(struct vcpu *v);
/* interrupt */
enum hvm_intblk nhvm_interrupt_blocked(struct vcpu *v);
+/* returns true if hardware supports alternate p2m's */
+static inline bool_t hvm_altp2m_supported(void)
+{
+return hvm_funcs.altp2m_supported;
+}
+
#ifndef NDEBUG
/* Permit use of the Forced Emulation Prefix in HVM guests */
extern bool_t opt_hvm_fep;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 02/13] VMX: VMFUNC and #VE definitions and detection.
Currently, neither is enabled globally but may be enabled on a per-VCPU
basis by the altp2m code.
Remove the check for EPTE bit 63 == zero in ept_split_super_page(), as
that bit is now hardware-defined.
Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
---
xen/arch/x86/hvm/vmx/vmcs.c| 42 +++---
xen/arch/x86/mm/p2m-ept.c | 1 -
xen/include/asm-x86/hvm/vmx/vmcs.h | 14 +++--
xen/include/asm-x86/hvm/vmx/vmx.h | 13 +++-
xen/include/asm-x86/msr-index.h| 1 +
5 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 4c5ceb5..bc1cabd 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -101,6 +101,8 @@ u32 vmx_secondary_exec_control __read_mostly;
u32 vmx_vmexit_control __read_mostly;
u32 vmx_vmentry_control __read_mostly;
u64 vmx_ept_vpid_cap __read_mostly;
+u64 vmx_vmfunc __read_mostly;
+bool_t vmx_virt_exception __read_mostly;
const u32 vmx_introspection_force_enabled_msrs[] = {
MSR_IA32_SYSENTER_EIP,
@@ -140,6 +142,8 @@ static void __init vmx_display_features(void)
P(cpu_has_vmx_virtual_intr_delivery, "Virtual Interrupt Delivery");
P(cpu_has_vmx_posted_intr_processing, "Posted Interrupt Processing");
P(cpu_has_vmx_vmcs_shadowing, "VMCS shadowing");
+P(cpu_has_vmx_vmfunc, "VM Functions");
+P(cpu_has_vmx_virt_exceptions, "Virtualisation Exceptions");
P(cpu_has_vmx_pml, "Page Modification Logging");
#undef P
@@ -185,6 +189,7 @@ static int vmx_init_vmcs_config(void)
u64 _vmx_misc_cap = 0;
u32 _vmx_vmexit_control;
u32 _vmx_vmentry_control;
+u64 _vmx_vmfunc = 0;
bool_t mismatch = 0;
rdmsr(MSR_IA32_VMX_BASIC, vmx_basic_msr_low, vmx_basic_msr_high);
@@ -230,7 +235,9 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_ENABLE_EPT |
SECONDARY_EXEC_ENABLE_RDTSCP |
SECONDARY_EXEC_PAUSE_LOOP_EXITING |
- SECONDARY_EXEC_ENABLE_INVPCID);
+ SECONDARY_EXEC_ENABLE_INVPCID |
+ SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
+ SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);
rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
@@ -341,6 +348,24 @@ static int vmx_init_vmcs_config(void)
|| !(_vmx_vmexit_control & VM_EXIT_ACK_INTR_ON_EXIT) )
_vmx_pin_based_exec_control &= ~ PIN_BASED_POSTED_INTERRUPT;
+/* The IA32_VMX_VMFUNC MSR exists only when VMFUNC is available */
+if ( _vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_VM_FUNCTIONS )
+{
+rdmsrl(MSR_IA32_VMX_VMFUNC, _vmx_vmfunc);
+
+/*
+ * VMFUNC leaf 0 (EPTP switching) must be supported.
+ *
+ * Or we just don't use VMFUNC.
+ */
+if ( !(_vmx_vmfunc & VMX_VMFUNC_EPTP_SWITCHING) )
+_vmx_secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_VM_FUNCTIONS;
+}
+
+/* Virtualization exceptions are only enabled if VMFUNC is enabled */
+if ( !(_vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) )
+_vmx_secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
+
min = 0;
opt = VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_BNDCFGS;
_vmx_vmentry_control = adjust_vmx_controls(
@@ -361,6 +386,9 @@ static int vmx_init_vmcs_config(void)
vmx_vmentry_control= _vmx_vmentry_control;
vmx_basic_msr = ((u64)vmx_basic_msr_high << 32) |
vmx_basic_msr_low;
+vmx_vmfunc = _vmx_vmfunc;
+vmx_virt_exception = !!(_vmx_secondary_exec_control &
+ SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);
vmx_display_features();
/* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */
@@ -397,6 +425,9 @@ static int vmx_init_vmcs_config(void)
mismatch |= cap_check(
"EPT and VPID Capability",
vmx_ept_vpid_cap, _vmx_ept_vpid_cap);
+mismatch |= cap_check(
+"VMFUNC Capability",
+vmx_vmfunc, _vmx_vmfunc);
if ( cpu_has_vmx_ins_outs_instr_info !=
!!(vmx_basic_msr_high & (VMX_BASIC_INS_OUT_INFO >> 32)) )
{
@@ -967,6 +998,11 @@ static int construct_vmcs(struct vcpu *v)
/* Do not enable Monitor Trap Flag unless start single step debug */
v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
+/* Disable VMFUNC and #VE for now: they may be enabled later by altp2m. */
+v->arch.hvm_vmx.secondary_exec_control &=
+~(SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
+ SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);
+
if ( is_pvh_domain(d) )
{
/* Disable virtual apics, TPR */
@@ -1790,9 +1826,9 @@ void vmcs_dump_vcpu(struct vcpu *v)
printk("PL
[Xen-devel] Blktap 3.0.0 improvement
Hello, I want to know about Blktap asynchronous i/o read write operations on VHD. I want to know detail flow of program block-VHD.c . How the read write operations are performed on VHD . And any improvement in code would be done for better read write operations. Description about dynamic disk structure. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/7] libxc: fix uninitialized variable in xc_cpuid_pv_policy()
If xc_domain_get_guest_width were to fail, guest_width is not set, and
hence guest_64bit becomes undefined.
Fix is to initialise to 0, and report error if call fails.
Signed-off-by: Jennifer Herbert
---
tools/libxc/xc_cpuid_x86.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index c97f91a..847b701 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -437,14 +437,16 @@ static void xc_cpuid_pv_policy(
{
DECLARE_DOMCTL;
unsigned int guest_width;
-int guest_64bit;
+int guest_64bit = 0;
char brand[13];
uint64_t xfeature_mask;
xc_cpuid_brand_get(brand);
-xc_domain_get_guest_width(xch, domid, &guest_width);
-guest_64bit = (guest_width == 8);
+if (xc_domain_get_guest_width(xch, domid, &guest_width) == 0)
+guest_64bit = (guest_width == 8);
+else
+ERROR("Could not read guest word width.");
/* Detecting Xen's atitude towards XSAVE */
memset(&domctl, 0, sizeof(domctl));
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/7] libxc: Fix uninitialized valiables in xc_cpuid_hvm_policy()
If xc_hvm_param_get fails, is_pae and/or is_nestedhvm are left undefined.
This patch Indicates error and defaults to false.
Signed-off-by: Jennifer Herbert
---
tools/libxc/xc_cpuid_x86.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 847b701..cc6f18a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -268,11 +268,16 @@ static void xc_cpuid_hvm_policy(
{
DECLARE_DOMCTL;
char brand[13];
-uint64_t val;
-int is_pae, is_nestedhvm;
+uint64_t val = 0;
+int is_pae;
+int is_nestedhvm = 0;
uint64_t xfeature_mask;
+int rc;
+
+rc = xc_hvm_param_get(xch, domid, HVM_PARAM_PAE_ENABLED, &val);
+if ( rc < 0 )
+ ERROR("xc_hvm_param_get failed to get PAE_ENABLED with rc %d\n", rc);
-xc_hvm_param_get(xch, domid, HVM_PARAM_PAE_ENABLED, &val);
is_pae = !!val;
/* Detecting Xen's atitude towards XSAVE */
@@ -282,8 +287,11 @@ static void xc_cpuid_hvm_policy(
do_domctl(xch, &domctl);
xfeature_mask = domctl.u.vcpuextstate.xfeature_mask;
-xc_hvm_param_get(xch, domid, HVM_PARAM_NESTEDHVM, &val);
-is_nestedhvm = !!val;
+rc = xc_hvm_param_get(xch, domid, HVM_PARAM_NESTEDHVM, &val);
+if ( rc >= 0 )
+is_nestedhvm = !!val;
+else
+ERROR("xc_hvm_param_get failed to get NESTEDHVM with rc %d\n", rc);
switch ( input[0] )
{
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 6/7] libxc: Fix misleading use of strncpy code in build_hvm_info()
hvm_info->signature is not a string, but an 64 bit int, and is not NULL terminated. The use of strncpy to populate it is inappropriate and potentially misleading. A cursory glance might have you thinking someone had miscounted the length of the string literal - not realising it was intentionally cropping of the null termination. Also, since we wish to initialise all of hvm_info->signature, and certainly no more, the use of sizeof is safer. Signed-off-by: Jennifer Herbert --- tools/libxc/xc_hvm_build_x86.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c index 003ea06..ec5ef4d 100644 --- a/tools/libxc/xc_hvm_build_x86.c +++ b/tools/libxc/xc_hvm_build_x86.c @@ -99,7 +99,7 @@ static void build_hvm_info(void *hvm_info_page, memset(hvm_info_page, 0, PAGE_SIZE); /* Fill in the header. */ -strncpy(hvm_info->signature, "HVM INFO", 8); +memcpy(hvm_info->signature, "HVM INFO", sizeof(hvm_info->signature)); hvm_info->length = sizeof(struct hvm_info_table); /* Sensible defaults: these can be overridden by the caller. */ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/7] libxc: Prevent dereferencing NULL pointers returned from xc_dom_allocate()
The return from xc_dom_allocate is not checked for a NULL value. This patch fixes this, causing it to return from the function with an error. Signed-off-by: Jennifer Herbert --- tools/libxc/xc_dom_compat_linux.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c index 2c14a0f..617cd96 100644 --- a/tools/libxc/xc_dom_compat_linux.c +++ b/tools/libxc/xc_dom_compat_linux.c @@ -91,6 +91,8 @@ int xc_linux_build_mem(xc_interface *xch, uint32_t domid, xc_dom_loginit(xch); dom = xc_dom_allocate(xch, cmdline, features); +if (dom == NULL) +return -1; if ( (rc = xc_dom_kernel_mem(dom, image_buffer, image_size)) != 0 ) goto out; if ( initrd && ((rc = xc_dom_ramdisk_mem(dom, initrd, initrd_len)) != 0) ) @@ -123,6 +125,8 @@ int xc_linux_build(xc_interface *xch, uint32_t domid, xc_dom_loginit(xch); dom = xc_dom_allocate(xch, cmdline, features); +if (dom == NULL) +return -1; if ( (rc = xc_dom_kernel_file(dom, image_name)) != 0 ) goto out; if ( initrd_name && strlen(initrd_name) && @@ -146,6 +150,8 @@ int xc_get_bit_size(xc_interface *xch, int rc; *bit_size = 0; dom = xc_dom_allocate(xch, cmdline, features); +if (dom == NULL) +return -1; if ( (rc = xc_dom_kernel_file(dom, image_name)) != 0 ) goto out; if ( (rc = xc_dom_parse_image(dom)) != 0 ) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/7] libxc: Removing dead code from xc_dom_allocate()
The only place that jumps to 'err:' does so because !dom, which is rechecked in 'err:'. This patch simplifies, giving the same result. Signed-off-by: Jennifer Herbert --- tools/libxc/xc_dom_core.c |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c index b100ce1..cde943c 100644 --- a/tools/libxc/xc_dom_core.c +++ b/tools/libxc/xc_dom_core.c @@ -720,7 +720,7 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch, __FUNCTION__, cmdline, features); dom = malloc(sizeof(*dom)); if ( !dom ) -goto err; +return NULL; memset(dom, 0, sizeof(*dom)); dom->xch = xch; @@ -742,11 +742,6 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch, dom->alloc_malloc += sizeof(*dom); return dom; - - err: -if ( dom ) -xc_dom_release(dom); -return NULL; } int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 7/7] libxc: Prevent NULL pointer dereference in stdiostream_vmessage()
Unlikely that it may seem localtime_r could fail, which would result in a null pointer dereference. In this case, one can simply just skip logging the date/time, and logging anything is more useful then nothing. Signed-off-by: Jennifer Herbert --- tools/libxc/xtl_logger_stdio.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/tools/libxc/xtl_logger_stdio.c b/tools/libxc/xtl_logger_stdio.c index d8646e0..74d66a5 100644 --- a/tools/libxc/xtl_logger_stdio.c +++ b/tools/libxc/xtl_logger_stdio.c @@ -61,10 +61,11 @@ static void stdiostream_vmessage(xentoollog_logger *logger_in, struct tm lt_buf; time_t now = time(0); struct tm *lt= localtime_r(&now, <_buf); -fprintf(lg->f, "%04d-%02d-%02d %02d:%02d:%02d %s ", -lt->tm_year+1900, lt->tm_mon+1, lt->tm_mday, -lt->tm_hour, lt->tm_min, lt->tm_sec, -tzname[!!lt->tm_isdst]); +if (lt != NULL) +fprintf(lg->f, "%04d-%02d-%02d %02d:%02d:%02d %s ", +lt->tm_year+1900, lt->tm_mon+1, lt->tm_mday, +lt->tm_hour, lt->tm_min, lt->tm_sec, +tzname[!!lt->tm_isdst]); } if (lg->flags & XTL_STDIOSTREAM_SHOW_PID) fprintf(lg->f, "[%lu] ", (unsigned long)getpid()); -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/7] libxc: Use const pointer in local_file_dump()
By adding the const keyword, it is clearer to people and static analysis
tools that no changes to the data are to be made.
Signed-off-by: Jennifer Herbert
---
tools/libxc/xc_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxc/xc_core.c b/tools/libxc/xc_core.c
index dfa424b..f759fd6 100644
--- a/tools/libxc/xc_core.c
+++ b/tools/libxc/xc_core.c
@@ -926,7 +926,7 @@ struct dump_args {
static int local_file_dump(xc_interface *xch,
void *args, char *buffer, unsigned int length)
{
-struct dump_args *da = args;
+const struct dump_args *da = args;
if ( write_exact(da->fd, buffer, length) == -1 )
{
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/7] libxc: Fix a number of coverity issues.
Fix a number of coverity issues in libxc. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] run QEMU as non-root
On 07/01/2015 04:42 AM, Stefano Stabellini wrote: On Tue, 30 Jun 2015, Jim Fehlig wrote: On 06/30/2015 07:55 AM, Stefano Stabellini wrote: [...] b/docs/misc/qemu-deprivilege.txt new file mode 100644 index 000..783874b --- /dev/null +++ b/docs/misc/qemu-deprivilege.txt @@ -0,0 +1,26 @@ +For security reasons, libxl tries to create QEMU as non-root. +Libxl looks for the following users in this order: + +1) a user named "xen-qemuuser-domid$domid", +Where $domid is the domid of the domain being created. +This requires the reservation of 65535 uids from xen-qemuuser-domid1 +to xen-qemuuser-domid65535. To use this mechanism, you might want to +create a large number of users at installation time. For example: + +for ((i=1; i<65536; i++)) +do +adduser --system xen-qemuuser-domid$i +done + + +2) a user named "xen-qemuuser-shared" +As a fall back if both 1) and 2) fail, libxl will use a single user for +all QEMU instances. The user is named xen-qemuuser-shared. This is +less secure but still better than running QEMU as root. Using this is as +simple as creating just one more user on your host: + +adduser --system xen-qemuuser-shared + + +3) root +As a last resort, libxl will start QEMU as root. The more I think about it, the more I feel libxl is the wrong place for this policy. As mentioned earlier [0], libvirt allows apps to control the user:group policy. It is already supported by the qemu driver. It could be used by the libxl driver to inform libxl that the emulator (and other binaries?) it spawns should be in the context of the specified user:group. Regards, Jim [0] http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02139.html Are you suggesting to expose a per-domain user:group setting that can be passed down by libvirt? Maybe something under libxl_domain_build_info.u.hvm? Yes. But should it be restricted to .hvm? Maybe it will be useful now (or in the future) for pv too. E.g. older pv bootloaders that run in dom0 could be executed as the user:group. Then I could move the code below to xl_cmdimpl.c, making it xl specific (rather than libxl). Right. Which means adding 'user=' and 'group=' to xl.cfg, correct? If so, perhaps xl.conf should provide "xl-wide" defaults, applicable to all domains created with xl that don't contain explicit 'user=' and 'group='. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 for Xen 4.6 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler
On Wed, Jul 1, 2015 at 7:50 AM, Dario Faggioli wrote: > On Wed, 2015-07-01 at 09:48 +0100, Ian Campbell wrote: >> On Tue, 2015-06-30 at 17:54 -0700, Meng Xu wrote: >> > 2015-06-30 9:19 GMT-07:00 Ian Campbell : >> > > Note that this field is not the same as the others in this struct, it is >> > > in effect part of the "key" while the others are the "values". >> > > >> > >> > vcpuid in the libxl is not the key but the value. >> > >> > When it is passed into hypervisor, vcpuid acts as the key to identify >> > which VCPU. vcpuid should be be negative when it is passed to >> > hypervisor. >> > >> > Do you have any concerns about assigning the initial value of vcpuid as -1? >> >> libxl needs to do _something_ if it is passed a vcpuid=-1. What is that >> something? >> > Exactly. > > Meng, Chong, maybe what you are missing from Ian's point is the fact > that libxl is a library on top of which to build more advanced > toolstack, it is not just something that the xl command line tool links > to. > > Therefore, it has to work even when it is not xl that makes the API > calls. Actually, I better say that --not only it has to work-- it has to > be easy and comfortable to use from high level components different than > xl. > > The outcome of this reasoning is that, you can't just assume that a > default value does not matter much, because every code path in _xl_ > overrides it. Everything that is in libxl must make sense in libxl > per-se, even without bringing xl into the picture. > > So, in this case, you need to think whether it is convenient > _in_general_, not only wrt xl, to have -1 as default value for vcpuid > and, if yes, what happens if such default is not overridden and libxl > gets to deal with it! > > Hope this helps... If this was not the issue, sorry for the noise. :-) I did some sanity check about the vcpuid in hypervisor. Maybe that's not enough. I'll add other check on vcpuid in libxl (sched_rtds_vcpu_get/set) to ensure vcpuid has a valid value. Chong > > Regards, > Dario > > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) -- Chong Li Department of Computer Science and Engineering Washington University in St.louis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
On 01/07/15 17:13, Stefano Stabellini wrote: > On Wed, 1 Jul 2015, Andrew Cooper wrote: >> On 01/07/15 16:51, Boris Ostrovsky wrote: >>> On 07/01/2015 11:46 AM, Andrew Cooper wrote: On 01/07/15 15:46, Roger Pau Monne wrote: > Introduce a new DOMCTL flag that can be used to disable device > emulation > inside of Xen for HVM guests. The following emulated devices are > disabled > when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, > lapic, > pic and pmu. Also all the MMIO handlers are disabled. > > Signed-off-by: Roger Pau Monné > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Boris Ostrovsky > Cc: Suravee Suthikulpanit > Cc: Aravind Gopalakrishnan > Cc: Jun Nakajima > Cc: Eddie Dong > Cc: Kevin Tian I would be hesitant to have a blanket change like this. Consider APICV/AVIC. For performance reasons, we absolutely want HVM and PVH to make use of them, as they are substantially more efficient using hardware support than evening using plain evtchn hypercalls. However, the flipside is that we must provide an LAPIC emulation to cover the bits which hardware cannot virtualise. As a random idea, how about having a new hypercall or hvmparam which provides a bitmap of permitted emulators? This would allow far finer grain control over what is and isn't available to a domain. >>> I think we also need to decide on which subsets of emulators we are >>> going to support, otherwise test matrix will become pretty big. For >>> example, initially we may want to allow all (for what we now call HVM) >>> or none (PVH). >> Right, but that can currently be enforced with an "if ( arg != 0 && arg >> != ~0 ) return -EOPNOTSUPP;" in the hypercall handler for now. >> >> It still leaves us with the ability to add in LAPIC emulation in the >> future by changing the auditing. A blanket "no emulation" boolean is >> very much harder to relax in the future. > APICV is a bit of a special case, because it is partially virtualized in > hardware. Not in the slightest. It is *exactly* the same as existing hardware virt. Hardware does most of the work, but occasionally needs to break into Xen to mange thing. The difference is that we don't call some of the existing vmexits "emulating an x86 cpu", despite this being what is actually happening. > But in general, considering that the whole purpose of PVH as DomU is > security Says who? An entirely reasonable alternate opinion is "HVM without the emulation overhead". > , as a Xen user, I would not want any emulators running with PVH > guests. Otherwise I might as well run PV on HVM. That is fine from a security point of view, but is not shared by most users Xen. Most users of Xen want to squeeze every ounce of performance out of the hardware they paid $$$ for, and won't mind exposing an LAPIC implementation to a PVH guest, seeing as the same implementation is available to windows or existing PVHVM guests. (when eventually supported), offering host administrators a choice between more security or more performance is perfectly ok, but designing PVH to be secure at the deliberate detriment of performance is unacceptable. > Being able to enable/disable specific emulators sounds more future > proof, but in practice it is likely to lead to many broken non default > configs. Not if Xen has a sensible audit for combinations (which is precisely what I suggested). ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 05/19] xen: enable XENMEM_memory_map in hvm
On Tue, Jun 23, 2015 at 10:57 AM, Tiejun Chen wrote: > This patch enables XENMEM_memory_map in hvm. So hvmloader can > use it to setup the e820 mappings. > > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Tiejun Chen > Reviewed-by: Tim Deegan > Reviewed-by: Kevin Tian > Acked-by: Jan Beulich FWIW: Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy
On Tue, Jun 23, 2015 at 10:57 AM, Tiejun Chen wrote:
> This patch extends the existing hypercall to support rdm reservation policy.
> We return error or just throw out a warning message depending on whether
> the policy is "strict" or "relaxed" when reserving RDM regions in pfn space.
> Note in some special cases, e.g. add a device to hwdomain, and remove a
> device from user domain, 'relaxed' is fine enough since this is always safe
> to hwdomain.
>
> CC: Tim Deegan
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Suravee Suthikulpanit
> CC: Aravind Gopalakrishnan
> CC: Ian Campbell
> CC: Stefano Stabellini
> CC: Yang Zhang
> CC: Kevin Tian
> Signed-off-by: Tiejun Chen
OK, now that I've had a chance to go through the entire series, one
more comment on this patch:
> * Add code comments to describer why we fix to set a policy flag in some
> cases like adding a device to hwdomain, and removing a device from user
> domain.
[snip]
> @@ -1898,7 +1899,13 @@ static int intel_iommu_add_device(u8 devfn, struct
> pci_dev *pdev)
> PCI_BUS(bdf) == pdev->bus &&
> PCI_DEVFN2(bdf) == devfn )
> {
> -ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
> +/*
> + * RMRR is always reserved on e820 so either of flag
> + * is fine for hardware domain and here we'd like to
> + * pass XEN_DOMCTL_DEV_RDM_RELAXED.
> + */
> +ret = rmrr_identity_mapping(pdev->domain, 1, rmrr,
> +XEN_DOMCTL_DEV_RDM_RELAXED);
So two things.
First, you assert that the value here won't matter, because the
hardware domain is guaranteed never to have a conflict.
Which is likely to be true almost all the time; but the question is,
*if* something goes wrong, what should happen?
For instance, suppose that someone accidentally introduces a bug in
Xen that messes up or ignores reading a portion of the e820 map under
certain circumstances. What should happen?
If you set this to RELAXED, this clash will be silently ignored; which
means that devices that need RMRR will simply malfunction in weird
ways without any warning messages having been printed that might give
someone a hint about what is going on.
If you set this to STRICT, then this clash will print an error
message, but as far as I can tell, the rest of the device assignment
will continue as normal. (Please correct me if I've followed the code
wrong.)
Since the device should be just as functional (or not functional)
either way, but in the STRICT case should actually print an error
message which someone might notice, it seems to me that STRICT is a
better option for the hardware domain.
Secondly, you assert in response to Kevin's question in v3 that this
path is only reachable when assigning to the hardware domain. I think
you at least need to update the comment here to indicate that's what
you think; it's not at all obvious just from looking at the function
that this is true. And if we do end up doing something besides
STRICT, we should check to make sure that pdev->domain really *is* the
hardware domain before acting like it is.
> if ( ret )
> dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping failed\n",
> pdev->domain->domain_id);
> @@ -1939,7 +1946,8 @@ static int intel_iommu_remove_device(u8 devfn, struct
> pci_dev *pdev)
> PCI_DEVFN2(bdf) != devfn )
> continue;
>
> -rmrr_identity_mapping(pdev->domain, 0, rmrr);
> +rmrr_identity_mapping(pdev->domain, 0, rmrr,
> + XEN_DOMCTL_DEV_RDM_RELAXED);
> }
Same here wrt STRICT.
After those changes (a single RDM_RELAXED flag, passing STRICT in for
the hardware domain) then I think this patch is in good shape.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
On Wed, 1 Jul 2015, Andrew Cooper wrote: > On 01/07/15 16:51, Boris Ostrovsky wrote: > > On 07/01/2015 11:46 AM, Andrew Cooper wrote: > >> On 01/07/15 15:46, Roger Pau Monne wrote: > >>> Introduce a new DOMCTL flag that can be used to disable device > >>> emulation > >>> inside of Xen for HVM guests. The following emulated devices are > >>> disabled > >>> when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, > >>> lapic, > >>> pic and pmu. Also all the MMIO handlers are disabled. > >>> > >>> Signed-off-by: Roger Pau Monné > >>> Cc: Jan Beulich > >>> Cc: Andrew Cooper > >>> Cc: Boris Ostrovsky > >>> Cc: Suravee Suthikulpanit > >>> Cc: Aravind Gopalakrishnan > >>> Cc: Jun Nakajima > >>> Cc: Eddie Dong > >>> Cc: Kevin Tian > >> I would be hesitant to have a blanket change like this. > >> > >> Consider APICV/AVIC. For performance reasons, we absolutely want HVM > >> and PVH to make use of them, as they are substantially more efficient > >> using hardware support than evening using plain evtchn hypercalls. > >> > >> However, the flipside is that we must provide an LAPIC emulation to > >> cover the bits which hardware cannot virtualise. > >> > >> As a random idea, how about having a new hypercall or hvmparam which > >> provides a bitmap of permitted emulators? This would allow far finer > >> grain control over what is and isn't available to a domain. > > > > I think we also need to decide on which subsets of emulators we are > > going to support, otherwise test matrix will become pretty big. For > > example, initially we may want to allow all (for what we now call HVM) > > or none (PVH). > > Right, but that can currently be enforced with an "if ( arg != 0 && arg > != ~0 ) return -EOPNOTSUPP;" in the hypercall handler for now. > > It still leaves us with the ability to add in LAPIC emulation in the > future by changing the auditing. A blanket "no emulation" boolean is > very much harder to relax in the future. APICV is a bit of a special case, because it is partially virtualized in hardware. But in general, considering that the whole purpose of PVH as DomU is security, as a Xen user, I would not want any emulators running with PVH guests. Otherwise I might as well run PV on HVM. Being able to enable/disable specific emulators sounds more future proof, but in practice it is likely to lead to many broken non default configs.___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-07-08)
On 07/01/2015 11:57 AM, Ian Campbell wrote: The next Xen technical call will be at: Wed 8 Jul 17:00:00 BST 2015 `date -d @1436371200` See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html for more information on the call. Please let me know (CC-ing the list) any topics which you would like to discuss. It might be useful to include: * References to any relevant/recent mailing list threads; * Other people who you think should be involved in the discussion (and CC them); If you would like to attend then please let me know so I can send you the dial in details. Given that there is fair amount of PVH-related work happening now (Roger's, Elena's and mine) perhaps we should have a discussion about that to see where we are going? Andrew, Tim, Roger, Jan (if he is back from vacation), Elena, Konrad and David would be good to have present. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-07-08)
On 01/07/15 17:15, Boris Ostrovsky wrote: > On 07/01/2015 11:57 AM, Ian Campbell wrote: >> The next Xen technical call will be at: >> Wed 8 Jul 17:00:00 BST 2015 >> `date -d @1436371200` >> >> See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html >> for more information on the call. >> >> Please let me know (CC-ing the list) any topics which you would like to >> discuss. It might be useful to include: >> >>* References to any relevant/recent mailing list threads; >>* Other people who you think should be involved in the discussion >> (and >> CC them); >> >> If you would like to attend then please let me know so I can send you >> the >> dial in details. > > > Given that there is fair amount of PVH-related work happening now > (Roger's, Elena's and mine) perhaps we should have a discussion about > that to see where we are going? > > Andrew, Tim, Roger, Jan (if he is back from vacation), Elena, Konrad > and David would be good to have present. > > -boris Sounds like a plan. I believe Jan will be back by then. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Convert map_domain_page() to use the new mfn_t type
On 01/07/15 14:41, Ben Catterall wrote:
> Reworked the internals and declaration, applying (un)boxing
> where needed. Converted calls to map_domain_page() to
> provide mfn_t types, boxing where needed.
>
> Signed-off-by: Ben Catterall
> ---
> xen/arch/arm/domain_build.c | 2 +-
> xen/arch/arm/kernel.c | 2 +-
> xen/arch/arm/mm.c | 12 +-
> xen/arch/arm/p2m.c| 4 ++--
> xen/arch/arm/traps.c | 4 ++--
> xen/arch/x86/debug.c | 10
> xen/arch/x86/domain.c | 4 ++--
> xen/arch/x86/domain_build.c | 10
> xen/arch/x86/domain_page.c| 22 -
> xen/arch/x86/domctl.c | 2 +-
> xen/arch/x86/mm.c | 40
> +++
> xen/arch/x86/mm/guest_walk.c | 2 +-
> xen/arch/x86/mm/hap/guest_walk.c | 2 +-
> xen/arch/x86/mm/mem_sharing.c | 4 ++--
> xen/arch/x86/mm/p2m-ept.c | 22 -
> xen/arch/x86/mm/p2m-pod.c | 8 +++
> xen/arch/x86/mm/p2m-pt.c | 28 +++---
> xen/arch/x86/mm/p2m.c | 2 +-
> xen/arch/x86/mm/paging.c | 32 -
> xen/arch/x86/mm/shadow/common.c | 2 +-
> xen/arch/x86/mm/shadow/multi.c| 4 ++--
> xen/arch/x86/mm/shadow/private.h | 2 +-
> xen/arch/x86/smpboot.c| 2 +-
> xen/arch/x86/tboot.c | 4 ++--
> xen/arch/x86/traps.c | 12 +-
> xen/arch/x86/x86_64/mm.c | 14 +--
> xen/arch/x86/x86_64/traps.c | 10
> xen/arch/x86/x86_emulate.c| 10
> xen/common/grant_table.c | 4 ++--
> xen/common/kexec.c| 4 ++--
> xen/common/kimage.c | 10
> xen/common/memory.c | 6 ++---
> xen/common/tmem_xen.c | 6 ++---
> xen/drivers/passthrough/amd/iommu_guest.c | 10
> xen/drivers/passthrough/amd/iommu_map.c | 14 +--
> xen/drivers/passthrough/vtd/x86/vtd.c | 2 +-
> xen/include/asm-x86/hap.h | 2 +-
> xen/include/asm-x86/page.h| 6 ++---
> xen/include/asm-x86/paging.h | 2 +-
> xen/include/xen/domain_page.h | 8 +++
> 40 files changed, 173 insertions(+), 173 deletions(-)
Wow - this is a rather larger patch than I would have guessed. Good work!
Reviewed-by: Andrew Cooper
As this is a cleanup patch, I have a few further suggestions.
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e9cb8a9..01add40 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1322,7 +1322,7 @@ static void initrd_load(struct kernel_info *kinfo)
> return;
> }
>
> -dst = map_domain_page(ma>>PAGE_SHIFT);
> +dst = map_domain_page(_mfn(ma>>PAGE_SHIFT));
>
> copy_from_paddr(dst + s, paddr + offs, l);
>
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 209c3dd..8b2bf9b 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -182,7 +182,7 @@ static void kernel_zimage_load(struct kernel_info *info)
> return;
> }
>
> -dst = map_domain_page(ma>>PAGE_SHIFT);
> +dst = map_domain_page(_mfn(ma>>PAGE_SHIFT));
These two hunks should use _mfn(paddr_to_mfn(ma)) rather than
open-coding paddr_to_mfn()
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 258d4c5..71c0fd9 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2263,7 +2263,7 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
> printk("Failed TTBR0 maddr lookup\n");
> goto done;
> }
> -first = map_domain_page(paddr>>PAGE_SHIFT);
> +first = map_domain_page(_mfn(paddr>>PAGE_SHIFT));
>
> offset = addr >> (12+10);
> printk("1ST[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
> @@ -2279,7 +2279,7 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
> printk("Failed L1 entry maddr lookup\n");
> goto done;
> }
> -second = map_domain_page(paddr>>PAGE_SHIFT);
> +second = map_domain_page(_mfn(paddr>>PAGE_SHIFT));
Similarly, these should be _mfn(paddr_to_mfn(paddr))
> diff --git a/xen/arch/x86/mm/shadow/private.h
> b/xen/arch/x86/mm/shadow/private.h
> index eff39dc..31b36ef 100644
> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/arch/x86/mm/shadow/private.h
> @@ -508,7 +508,7 @@ sh_mfn_is_a_page_table(mfn_t gmfn)
> static inline void *
> sh_map_domain_page(mfn_t mfn)
> {
> -return map_domain_page(mfn_x(mfn));
> +return map_domain_page(mfn);
> }
As a smaller f
Re: [Xen-devel] [PATCH 2/3] xen/domain_page: Convert copy/clear_domain_page() to using mfn_t
On 01/07/15 14:57, Andrew Cooper wrote: > On 01/07/15 14:41, Ben Catterall wrote: >> From: Andrew Cooper >> >> Signed-off-by: Andrew Cooper >> [Convert grant_table.c to pass mfn_t types and fix ARM compiling] >> >> Signed-off-by: Ben Catterall > > Reviwed-by: Andrew Cooper for the additions > beyond my half of the patch. > > Also CC'ing George and David as maintainers of areas touched. For this sort of tree-wide mechanical change I wouldn't generally expected to need acks/reviews from specific subsystem maintainers. I'm not sure I see the point of this series. >> --- a/xen/common/kimage.c >> +++ b/xen/common/kimage.c >> @@ -77,7 +77,7 @@ static struct page_info *kimage_alloc_zeroed_page(unsigned >> memflags) >> if ( !page ) >> return NULL; >> >> -clear_domain_page(page_to_mfn(page)); >> +clear_domain_page(_mfn(page_to_mfn(page))); Seems odd that page_to_mfn() doesn't return the correct type and needs the "cast". David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] xen/domain_page: Convert copy/clear_domain_page() to using mfn_t
On 01/07/15 17:07, David Vrabel wrote: > On 01/07/15 14:57, Andrew Cooper wrote: >> On 01/07/15 14:41, Ben Catterall wrote: >>> From: Andrew Cooper >>> >>> Signed-off-by: Andrew Cooper >>> [Convert grant_table.c to pass mfn_t types and fix ARM compiling] >>> >>> Signed-off-by: Ben Catterall >> Reviwed-by: Andrew Cooper for the additions >> beyond my half of the patch. >> >> Also CC'ing George and David as maintainers of areas touched. > For this sort of tree-wide mechanical change I wouldn't generally > expected to need acks/reviews from specific subsystem maintainers. Fair enough. >>> --- a/xen/common/kimage.c >>> +++ b/xen/common/kimage.c >>> @@ -77,7 +77,7 @@ static struct page_info >>> *kimage_alloc_zeroed_page(unsigned memflags) >>> if ( !page ) >>> return NULL; >>> >>> -clear_domain_page(page_to_mfn(page)); >>> +clear_domain_page(_mfn(page_to_mfn(page))); > Seems odd that page_to_mfn() doesn't return the correct type and needs > the "cast". page_to_mfn() and all the other similar helpers are also on the list of stuff needing cleaning up. The intermediate _mfn() call will eventually disappear, but updating everything together is massive task. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
On 01/07/15 16:51, Boris Ostrovsky wrote: > On 07/01/2015 11:46 AM, Andrew Cooper wrote: >> On 01/07/15 15:46, Roger Pau Monne wrote: >>> Introduce a new DOMCTL flag that can be used to disable device >>> emulation >>> inside of Xen for HVM guests. The following emulated devices are >>> disabled >>> when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, >>> lapic, >>> pic and pmu. Also all the MMIO handlers are disabled. >>> >>> Signed-off-by: Roger Pau Monné >>> Cc: Jan Beulich >>> Cc: Andrew Cooper >>> Cc: Boris Ostrovsky >>> Cc: Suravee Suthikulpanit >>> Cc: Aravind Gopalakrishnan >>> Cc: Jun Nakajima >>> Cc: Eddie Dong >>> Cc: Kevin Tian >> I would be hesitant to have a blanket change like this. >> >> Consider APICV/AVIC. For performance reasons, we absolutely want HVM >> and PVH to make use of them, as they are substantially more efficient >> using hardware support than evening using plain evtchn hypercalls. >> >> However, the flipside is that we must provide an LAPIC emulation to >> cover the bits which hardware cannot virtualise. >> >> As a random idea, how about having a new hypercall or hvmparam which >> provides a bitmap of permitted emulators? This would allow far finer >> grain control over what is and isn't available to a domain. > > I think we also need to decide on which subsets of emulators we are > going to support, otherwise test matrix will become pretty big. For > example, initially we may want to allow all (for what we now call HVM) > or none (PVH). Right, but that can currently be enforced with an "if ( arg != 0 && arg != ~0 ) return -EOPNOTSUPP;" in the hypercall handler for now. It still leaves us with the ability to add in LAPIC emulation in the future by changing the auditing. A blanket "no emulation" boolean is very much harder to relax in the future. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-07-08)
The next Xen technical call will be at: Wed 8 Jul 17:00:00 BST 2015 `date -d @1436371200` See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html for more information on the call. Please let me know (CC-ing the list) any topics which you would like to discuss. It might be useful to include: * References to any relevant/recent mailing list threads; * Other people who you think should be involved in the discussion (and CC them); If you would like to attend then please let me know so I can send you the dial in details. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
On 07/01/2015 11:46 AM, Andrew Cooper wrote: On 01/07/15 15:46, Roger Pau Monne wrote: Introduce a new DOMCTL flag that can be used to disable device emulation inside of Xen for HVM guests. The following emulated devices are disabled when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, lapic, pic and pmu. Also all the MMIO handlers are disabled. Signed-off-by: Roger Pau Monné Cc: Jan Beulich Cc: Andrew Cooper Cc: Boris Ostrovsky Cc: Suravee Suthikulpanit Cc: Aravind Gopalakrishnan Cc: Jun Nakajima Cc: Eddie Dong Cc: Kevin Tian I would be hesitant to have a blanket change like this. Consider APICV/AVIC. For performance reasons, we absolutely want HVM and PVH to make use of them, as they are substantially more efficient using hardware support than evening using plain evtchn hypercalls. However, the flipside is that we must provide an LAPIC emulation to cover the bits which hardware cannot virtualise. As a random idea, how about having a new hypercall or hvmparam which provides a bitmap of permitted emulators? This would allow far finer grain control over what is and isn't available to a domain. I think we also need to decide on which subsets of emulators we are going to support, otherwise test matrix will become pretty big. For example, initially we may want to allow all (for what we now call HVM) or none (PVH). -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
On 01/07/15 15:46, Roger Pau Monne wrote: > Introduce a new DOMCTL flag that can be used to disable device emulation > inside of Xen for HVM guests. The following emulated devices are disabled > when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, lapic, > pic and pmu. Also all the MMIO handlers are disabled. > > Signed-off-by: Roger Pau Monné > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Boris Ostrovsky > Cc: Suravee Suthikulpanit > Cc: Aravind Gopalakrishnan > Cc: Jun Nakajima > Cc: Eddie Dong > Cc: Kevin Tian I would be hesitant to have a blanket change like this. Consider APICV/AVIC. For performance reasons, we absolutely want HVM and PVH to make use of them, as they are substantially more efficient using hardware support than evening using plain evtchn hypercalls. However, the flipside is that we must provide an LAPIC emulation to cover the bits which hardware cannot virtualise. As a random idea, how about having a new hypercall or hvmparam which provides a bitmap of permitted emulators? This would allow far finer grain control over what is and isn't available to a domain. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 02/19] xen/x86/p2m: introduce set_identity_p2m_entry
On Tue, Jun 23, 2015 at 10:57 AM, Tiejun Chen wrote: > We will create this sort of identity mapping as follows: > > If the gfn space is unoccupied, we just set the mapping. If space > is already occupied by desired identity mapping, do nothing. > Otherwise, failure is returned. > > And we also add a returning value to guest_physmap_remove_page() > then make that as a better helper to clear such a p2m entry. > > CC: Tim Deegan > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Tiejun Chen > Reviewed-by: Kevin Tian FWIW: Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
> -Original Message- > From: Roger Pau Monné [mailto:roger@citrix.com] > Sent: 01 July 2015 16:35 > To: Paul Durrant; xen-de...@lists.xenproject.org > Cc: Kevin Tian; Jan Beulich; Jun Nakajima; Andrew Cooper; Eddie Dong; > Aravind Gopalakrishnan; Suravee Suthikulpanit; Boris Ostrovsky > Subject: Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated > devices for HVM guests > > El 01/07/15 a les 17.25, Paul Durrant ha escrit: > >> -Original Message- > >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > >> boun...@lists.xen.org] On Behalf Of Roger Pau Monne > >> Sent: 01 July 2015 15:46 > >> To: xen-de...@lists.xenproject.org > >> Cc: Kevin Tian; Jan Beulich; Jun Nakajima; Andrew Cooper; Eddie Dong; > >> Aravind Gopalakrishnan; Suravee Suthikulpanit; Boris Ostrovsky; Roger > Pau > >> Monne > >> Subject: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated > >> devices for HVM guests > >> > >> Introduce a new DOMCTL flag that can be used to disable device > emulation > >> inside of Xen for HVM guests. The following emulated devices are > disabled > >> when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, > >> lapic, > >> pic and pmu. Also all the MMIO handlers are disabled. > >> > >> Signed-off-by: Roger Pau Monné > > > > This is going to conflict badly with my recent emulation cleanup series. > > Yes, I've had to rebase to staging today and already found quite a lot > of conflicts, but that's fine. I think your emulation cleanup series > should make it easier to register specific MMIO handlers at runtime, and > I don't mind rebasing on top of yours. > Cool. I thought, after I sent the email, that it actually might make things easier for you :-) Paul > Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] run QEMU as non-root
On Wed, 1 Jul 2015, Dario Faggioli wrote: > On Wed, 2015-07-01 at 13:50 +0100, Stefano Stabellini wrote: > > --- /dev/null > > +++ b/docs/misc/qemu-deprivilege.txt > > @@ -0,0 +1,31 @@ > > +For security reasons, libxl tries to pass a non-root username to QEMU as > > +argument. During initialization QEMU calls setuid and setgid with the > > +user ID and the group ID of the user passed as argument. > > +Libxl looks for the following users in this order: > > + > > +1) a user named "xen-qemuuser-domid$domid", > > +Where $domid is the domid of the domain being created. > > +This requires the reservation of 65535 uids from xen-qemuuser-domid1 > > +to xen-qemuuser-domid65535. To use this mechanism, you might want to > > +create a large number of users at installation time. For example: > > + > > +for ((i=1; i<65536; i++)) > > +do > > +adduser --no-create-home --system xen-qemuuser-domid$i > > +done > > + > > +You might want to consider passing --group to adduser to create a new > > +group for each new user. > > + > This is, IMHO, a lot of policing, for something like libxl. > > I'm saying this only now because, although always being always dubious > about it, it was Jim's comment to v5 that made me realize it properly, > and you're own reply to him in that thread, would actually be a great > alternative! > > In fact, what about: > * in libxl: > - provide and honour (as first option) device_model_user, as you're > doing here; > - if the above is not provided, check the availability of the > 'shared' user, and use it if it's there; > - if that is not there either, use root. > * in xl (as you said yourself in v5's review): > - build up the per-domain username and (if available) use > device_model_user to pass it to libxl. That is of course possible and was my first suggestion in my reply. However after speaking with IanC, I was convinced that offering a good default security mechanism in libxl is better, so that all libxl users, including hyper for example, get good security by default without any need to do anything (except creating some users). I think that libvirt is a bit of a special case here, given that it already knows about users. I would expect most other toolstacks not to. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
El 01/07/15 a les 17.25, Paul Durrant ha escrit: >> -Original Message- >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- >> boun...@lists.xen.org] On Behalf Of Roger Pau Monne >> Sent: 01 July 2015 15:46 >> To: xen-de...@lists.xenproject.org >> Cc: Kevin Tian; Jan Beulich; Jun Nakajima; Andrew Cooper; Eddie Dong; >> Aravind Gopalakrishnan; Suravee Suthikulpanit; Boris Ostrovsky; Roger Pau >> Monne >> Subject: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated >> devices for HVM guests >> >> Introduce a new DOMCTL flag that can be used to disable device emulation >> inside of Xen for HVM guests. The following emulated devices are disabled >> when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, >> lapic, >> pic and pmu. Also all the MMIO handlers are disabled. >> >> Signed-off-by: Roger Pau Monné > > This is going to conflict badly with my recent emulation cleanup series. Yes, I've had to rebase to staging today and already found quite a lot of conflicts, but that's fine. I think your emulation cleanup series should make it easier to register specific MMIO handlers at runtime, and I don't mind rebasing on top of yours. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] run QEMU as non-root
On Wed, 2015-07-01 at 13:50 +0100, Stefano Stabellini wrote: > --- /dev/null > +++ b/docs/misc/qemu-deprivilege.txt > @@ -0,0 +1,31 @@ > +For security reasons, libxl tries to pass a non-root username to QEMU as > +argument. During initialization QEMU calls setuid and setgid with the > +user ID and the group ID of the user passed as argument. > +Libxl looks for the following users in this order: > + > +1) a user named "xen-qemuuser-domid$domid", > +Where $domid is the domid of the domain being created. > +This requires the reservation of 65535 uids from xen-qemuuser-domid1 > +to xen-qemuuser-domid65535. To use this mechanism, you might want to > +create a large number of users at installation time. For example: > + > +for ((i=1; i<65536; i++)) > +do > +adduser --no-create-home --system xen-qemuuser-domid$i > +done > + > +You might want to consider passing --group to adduser to create a new > +group for each new user. > + This is, IMHO, a lot of policing, for something like libxl. I'm saying this only now because, although always being always dubious about it, it was Jim's comment to v5 that made me realize it properly, and you're own reply to him in that thread, would actually be a great alternative! In fact, what about: * in libxl: - provide and honour (as first option) device_model_user, as you're doing here; - if the above is not provided, check the availability of the 'shared' user, and use it if it's there; - if that is not there either, use root. * in xl (as you said yourself in v5's review): - build up the per-domain username and (if available) use device_model_user to pass it to libxl. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Roger Pau Monne
> Sent: 01 July 2015 15:46
> To: xen-de...@lists.xenproject.org
> Cc: Kevin Tian; Jan Beulich; Jun Nakajima; Andrew Cooper; Eddie Dong;
> Aravind Gopalakrishnan; Suravee Suthikulpanit; Boris Ostrovsky; Roger Pau
> Monne
> Subject: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated
> devices for HVM guests
>
> Introduce a new DOMCTL flag that can be used to disable device emulation
> inside of Xen for HVM guests. The following emulated devices are disabled
> when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic,
> lapic,
> pic and pmu. Also all the MMIO handlers are disabled.
>
> Signed-off-by: Roger Pau Monné
This is going to conflict badly with my recent emulation cleanup series.
Paul
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Boris Ostrovsky
> Cc: Suravee Suthikulpanit
> Cc: Aravind Gopalakrishnan
> Cc: Jun Nakajima
> Cc: Eddie Dong
> Cc: Kevin Tian
> ---
> xen/arch/x86/domain.c | 2 +-
> xen/arch/x86/hvm/hpet.c | 8 +++-
> xen/arch/x86/hvm/hvm.c| 19 +--
> xen/arch/x86/hvm/intercept.c | 31 ---
>
> xen/arch/x86/hvm/pmtimer.c| 7 +++
> xen/arch/x86/hvm/rtc.c| 9 +
> xen/arch/x86/hvm/stdvga.c | 6 ++
> xen/arch/x86/hvm/svm/svm.c| 17 +
> xen/arch/x86/hvm/vioapic.c| 8 +++-
> xen/arch/x86/hvm/vlapic.c | 15 ---
> xen/arch/x86/hvm/vmsi.c | 2 +-
> xen/arch/x86/hvm/vmx/vmcs.c | 14 ++
> xen/arch/x86/hvm/vmx/vmx.c| 9 -
> xen/arch/x86/hvm/vpic.c | 3 +++
> xen/arch/x86/hvm/vpmu.c | 2 +-
> xen/arch/x86/hvm/vpt.c| 3 +++
> xen/common/domctl.c | 5 -
> xen/drivers/passthrough/amd/iommu_guest.c | 2 +-
> xen/include/asm-x86/hvm/domain.h | 4
> xen/include/asm-x86/hvm/hvm.h | 2 +-
> xen/include/asm-x86/hvm/io.h | 12 +++-
> xen/include/public/domctl.h | 3 +++
> xen/include/xen/sched.h | 9 +
> 23 files changed, 154 insertions(+), 38 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index a112953..0916c39 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -626,7 +626,7 @@ int arch_domain_create(struct domain *d, unsigned
> int domcr_flags,
>
> if ( has_hvm_container_domain(d) )
> {
> -if ( (rc = hvm_domain_initialise(d)) != 0 )
> +if ( (rc = hvm_domain_initialise(d, domcr_flags)) != 0 )
> {
> iommu_domain_destroy(d);
> goto fail;
> diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
> index 9585ca8..b4c121d 100644
> --- a/xen/arch/x86/hvm/hpet.c
> +++ b/xen/arch/x86/hvm/hpet.c
> @@ -504,7 +504,7 @@ static int hpet_range(struct vcpu *v, unsigned long
> addr)
> (addr < (HPET_BASE_ADDRESS + HPET_MMAP_SIZE)) );
> }
>
> -const struct hvm_mmio_ops hpet_mmio_ops = {
> +struct hvm_mmio_ops hpet_mmio_ops = {
> .check = hpet_range,
> .read = hpet_read,
> .write = hpet_write
> @@ -634,6 +634,9 @@ void hpet_init(struct domain *d)
> HPETState *h = domain_vhpet(d);
> int i;
>
> +if ( d->arch.hvm_domain.no_emu )
> +return;
> +
> memset(h, 0, sizeof(HPETState));
>
> rwlock_init(&h->lock);
> @@ -666,6 +669,9 @@ void hpet_deinit(struct domain *d)
> int i;
> HPETState *h = domain_vhpet(d);
>
> +if ( d->arch.hvm_domain.no_emu )
> +return;
> +
> write_lock(&h->lock);
>
> if ( hpet_enabled(h) )
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 535d622..66f95b2 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1423,7 +1423,7 @@ static int hvm_set_dm_domain(struct domain *d,
> domid_t domid)
> return rc;
> }
>
> -int hvm_domain_initialise(struct domain *d)
> +int hvm_domain_initialise(struct domain *d, unsigned int domcr_flags)
> {
> int rc;
>
> @@ -1491,10 +1491,12 @@ int hvm_domain_initialise(struct domain *d)
> return 0;
> }
>
> -hvm_init_guest_time(d);
> +if ( domcr_flags & DOMCRF_noemu )
> +d->arch.hvm_domain.no_emu = 1;
> +
> +setup_mmio_handlers(d);
>
> -d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
> -d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] =
> SHUTDOWN_reboot;
> +hvm_init_guest_time(d);
>
> vpic_init(d);
>
> @@ -1506,8 +1508,13 @@ int hvm_domain_initialise(struct domain *d)
>
> rtc_init(d);
>
> -register_portio_handler(d, 0xe9, 1, hvm_print_line);
> -register_por
[Xen-devel] [linux-3.16 test] 58996: regressions - FAIL
flight 58996 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/58996/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR. vs. 58447 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail like 58447 test-amd64-i386-libvirt 11 guest-start fail like 58447 test-amd64-i386-libvirt-xsm 11 guest-start fail like 58447 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58447 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-freebsd10-amd64 9 freebsd-install fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-freebsd10-i386 9 freebsd-install fail never pass test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail never pass test-amd64-amd64-xl-rtds 14 guest-localmigrate fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 guest-start.2fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: linux26749e751cc2be7bc0f17a6cca68f6e5c0675191 baseline version: linux162d64326176ee1916fb98323d810c78a7e3d042 People who touched revisions under test: Aaro Koskinen Adam Jackson Alex Deucher Andrew Morton Andy Lutomirski Axel Lin Chengyu Song Chris Mason Clemens Ladisch Dan Carpenter Dan Williams Dave Airlie David S. Miller David Woodhouse Dieter Jurzitza Dmitry Torokhov Eric Dumazet Fabio Estevam Fan Du Felipe Balbi Filipe Manana Florian Fainelli Greg Kroah-Hartman Gregory CLEMENT Gu Zheng H. Peter Anvin Hannes Frederic Sowa Hans de Goede Herbert Xu Horia Geanta Hui Wang Ian Campbell Ingo Molnar James Hogan Jan Kara Jani Nikula Jason A. Donenfeld Jean Delvare Jeff Mahoney Jenny Falkovich Jens Axboe Jiang Liu Jim Bride Jiri Pirko Johan Hovold Johannes Berg John D. Blair Jonathan Cameron Jérôme Glisse Kim Phillips Lars-Peter Clausen Laura Abbott Li RongQing Linus Torvalds Luis Henriques Lukas Wunner Mark Salyzyn Michael S. Tsirkin Michal Marek Nadav Haklai Nicholas Bellinger Nicholas Mc Guire nightmixes Nikolay Aleksandrov Oliver Grafe (v2) Patrick Riphagen Paul Cercueil Peter Feuerer Peter Hutterer Peter Kümmel Philipp Zabel Ralf Baechle Richard Cochran Ross Lagerwall Sachin Kamat Sagi Grimberg Sam Hung Shawn Bohrer Steffen Klassert Steve Cornelius Steven Rostedt Subbaraya Sundeep Bhatta Subbaraya Sundeep Bhatta Takashi Iwai Tejun Heo Thomas Gleixner Tim Gardner tommy.gag...@gmail.com Veaceslav Falico Victoria Milhoan Vince Weaver Vlad Yasevich Vladislav Yasevich Wang Long Wei Liu Wolfram Sang æ´ªä¸ç«¹ jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt
Re: [Xen-devel] [PATCH V2 3/3] xen/vm_event: Deny register writes if refused by vm_event reply
On 06/26/2015 11:28 AM, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> > @@ -2010,9 +2010,9 @@ static int vmx_cr_access(unsigned long
>> > exit_qualification)
>> > }
>> > case VMX_CONTROL_REG_ACCESS_TYPE_CLTS: {
>> > unsigned long old = curr->arch.hvm_vcpu.guest_cr[0];
>> > +hvm_event_crX(CR0, curr->arch.hvm_vcpu.guest_cr[0], old);
>> > curr->arch.hvm_vcpu.guest_cr[0] &= ~X86_CR0_TS;
>> > vmx_update_guest_cr(curr, 0);
>> > -hvm_event_crX(CR0, curr->arch.hvm_vcpu.guest_cr[0], old);
>> > HVMTRACE_0D(CLTS);
>> > break;
>> > }
> I suppose it is intentional to ignore a possible deny here? If so,
> shouldn't the be documented by way of a comment?
On second though, I will document it by way of a comment and leave it as
it is, since this is a corner case that would need special handling
(vmx_update_guest_cr(curr, 0), etc. vs how it's now done in
hvm_do_resume(), which would need a new parameter being passed around,
conditional code, etc.), and AFAIK this event is not interesting from a
DENY perspective and so not currently worth the overhead.
Looking at the code again, I'll also fix another mistake: when cutting
and pasting the hvm_event_crX() above to make it a pre-write event to be
consistent, the hvm_event_crX(CR0, curr->arch.hvm_vcpu.guest_cr[0], old)
code became wrong: old == curr->arch.hvm_vcpu.guest_cr[0], whereas
before, curr->arch.hvm_vcpu.guest_cr[0] &= ~X86_CR0_TS before that call.
I'll fix this too in V3.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
Introduce a new DOMCTL flag that can be used to disable device emulation
inside of Xen for HVM guests. The following emulated devices are disabled
when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, lapic,
pic and pmu. Also all the MMIO handlers are disabled.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Aravind Gopalakrishnan
Cc: Jun Nakajima
Cc: Eddie Dong
Cc: Kevin Tian
---
xen/arch/x86/domain.c | 2 +-
xen/arch/x86/hvm/hpet.c | 8 +++-
xen/arch/x86/hvm/hvm.c| 19 +--
xen/arch/x86/hvm/intercept.c | 31 ---
xen/arch/x86/hvm/pmtimer.c| 7 +++
xen/arch/x86/hvm/rtc.c| 9 +
xen/arch/x86/hvm/stdvga.c | 6 ++
xen/arch/x86/hvm/svm/svm.c| 17 +
xen/arch/x86/hvm/vioapic.c| 8 +++-
xen/arch/x86/hvm/vlapic.c | 15 ---
xen/arch/x86/hvm/vmsi.c | 2 +-
xen/arch/x86/hvm/vmx/vmcs.c | 14 ++
xen/arch/x86/hvm/vmx/vmx.c| 9 -
xen/arch/x86/hvm/vpic.c | 3 +++
xen/arch/x86/hvm/vpmu.c | 2 +-
xen/arch/x86/hvm/vpt.c| 3 +++
xen/common/domctl.c | 5 -
xen/drivers/passthrough/amd/iommu_guest.c | 2 +-
xen/include/asm-x86/hvm/domain.h | 4
xen/include/asm-x86/hvm/hvm.h | 2 +-
xen/include/asm-x86/hvm/io.h | 12 +++-
xen/include/public/domctl.h | 3 +++
xen/include/xen/sched.h | 9 +
23 files changed, 154 insertions(+), 38 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a112953..0916c39 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -626,7 +626,7 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
if ( has_hvm_container_domain(d) )
{
-if ( (rc = hvm_domain_initialise(d)) != 0 )
+if ( (rc = hvm_domain_initialise(d, domcr_flags)) != 0 )
{
iommu_domain_destroy(d);
goto fail;
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 9585ca8..b4c121d 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -504,7 +504,7 @@ static int hpet_range(struct vcpu *v, unsigned long addr)
(addr < (HPET_BASE_ADDRESS + HPET_MMAP_SIZE)) );
}
-const struct hvm_mmio_ops hpet_mmio_ops = {
+struct hvm_mmio_ops hpet_mmio_ops = {
.check = hpet_range,
.read = hpet_read,
.write = hpet_write
@@ -634,6 +634,9 @@ void hpet_init(struct domain *d)
HPETState *h = domain_vhpet(d);
int i;
+if ( d->arch.hvm_domain.no_emu )
+return;
+
memset(h, 0, sizeof(HPETState));
rwlock_init(&h->lock);
@@ -666,6 +669,9 @@ void hpet_deinit(struct domain *d)
int i;
HPETState *h = domain_vhpet(d);
+if ( d->arch.hvm_domain.no_emu )
+return;
+
write_lock(&h->lock);
if ( hpet_enabled(h) )
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 535d622..66f95b2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1423,7 +1423,7 @@ static int hvm_set_dm_domain(struct domain *d, domid_t
domid)
return rc;
}
-int hvm_domain_initialise(struct domain *d)
+int hvm_domain_initialise(struct domain *d, unsigned int domcr_flags)
{
int rc;
@@ -1491,10 +1491,12 @@ int hvm_domain_initialise(struct domain *d)
return 0;
}
-hvm_init_guest_time(d);
+if ( domcr_flags & DOMCRF_noemu )
+d->arch.hvm_domain.no_emu = 1;
+
+setup_mmio_handlers(d);
-d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
-d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot;
+hvm_init_guest_time(d);
vpic_init(d);
@@ -1506,8 +1508,13 @@ int hvm_domain_initialise(struct domain *d)
rtc_init(d);
-register_portio_handler(d, 0xe9, 1, hvm_print_line);
-register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
+if ( !d->arch.hvm_domain.no_emu )
+{
+d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] =
SHUTDOWN_reboot;
+register_portio_handler(d, 0xe9, 1, hvm_print_line);
+register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
+}
rc = hvm_funcs.domain_initialise(d);
if ( rc != 0 )
diff --git a/xen/arch/x86/hvm/intercept.c b/xen/arch/x86/hvm/intercept.c
index cc44733..714e29d 100644
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -32,7 +32,7 @@
#include
#include
-static const struct hvm_mmio_ops *const
+static struct hvm_mmio_ops *const
hvm_mmio_handlers[HVM_MMIO_HANDLER_NR] =
{
&hpet_mmio_
[Xen-devel] [PATCH v2 17/22] libxc: change the position of the special pages
Change the physical memory address of the special pages when there are no
emulated devices. On HVM guests the special pages have always been reserved
so that they end at the 0xff000 pfn, but there are some problems with this
approach when used without emulated devices:
- If we want to allow HVMlite to be used for Dom0 those special pages
cannot be placed inside of the MMIO hole or else they may clash with MMIO
regions of physical devices passed-through to Dom0.
- If there's no emulated devices the guests needs to access the console
page and the command line very early during boot. This is a problem for
FreeBSD at least, since the early page tables only map memory up to 1GiB.
So instead append the special pages after the kernel and ramdisk. The guest
must make sure it figures out the position of those pages very early during
boot, since the region is not marked as reserved in the memory map.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/xc_dom_x86.c | 50 ++--
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 45b1f03..1195400 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -58,15 +58,27 @@
#define SPECIALPAGE_IDENT_PT 6
#define SPECIALPAGE_CONSOLE 7
#define NR_SPECIAL_PAGES 8
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+#define LAST_SPECIAL_PFN 0xff000u
#define NR_IOREQ_SERVER_PAGES 8
-#define ioreq_server_pfn(x) (special_pfn(0) - NR_IOREQ_SERVER_PAGES + (x))
+#define ioreq_server_pfn(x, dom) (special_pfn(0, dom) - NR_IOREQ_SERVER_PAGES
+ (x))
#define bits_to_mask(bits) (((xen_vaddr_t)1 << (bits))-1)
#define round_down(addr, mask) ((addr) & ~(mask))
#define round_up(addr, mask) ((addr) | (mask))
+static unsigned long special_pfn(int index, struct xc_dom_image *dom)
+{
+unsigned long start_pfn;
+
+if ( dom->emulation )
+return (LAST_SPECIAL_PFN - NR_SPECIAL_PAGES + index);
+
+start_pfn = (dom->virt_alloc_end - dom->parms.virt_base) >>
+XC_DOM_PAGE_SHIFT(dom);
+return (start_pfn + index);
+}
+
/* get guest IO ABI protocol */
const char *xc_domain_get_native_protocol(xc_interface *xch,
uint32_t domid)
@@ -502,7 +514,7 @@ static void build_hvm_info(void *hvm_info_page, struct
xc_dom_image *dom)
/* Memory parameters. */
hvm_info->low_mem_pgend = dom->lowmem_end >> PAGE_SHIFT;
hvm_info->high_mem_pgend = dom->highmem_end >> PAGE_SHIFT;
-hvm_info->reserved_mem_pgstart = ioreq_server_pfn(0);
+hvm_info->reserved_mem_pgstart = ioreq_server_pfn(0, dom);
/* Finish with the checksum. */
for ( i = 0, sum = 0; i < hvm_info->length; i++ )
@@ -532,7 +544,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
/* Allocate and clear special pages. */
for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
-special_array[i] = special_pfn(i);
+special_array[i] = special_pfn(i, dom);
rc = xc_domain_populate_physmap_exact(xch, domid, NR_SPECIAL_PAGES, 0, 0,
special_array);
@@ -542,23 +554,23 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
goto error_out;
}
-if ( xc_clear_domain_pages(xch, domid, special_pfn(0), NR_SPECIAL_PAGES) )
+if ( xc_clear_domain_pages(xch, domid, special_pfn(0, dom),
NR_SPECIAL_PAGES) )
goto error_out;
xc_hvm_param_set(xch, domid, HVM_PARAM_STORE_PFN,
- special_pfn(SPECIALPAGE_XENSTORE));
+ special_pfn(SPECIALPAGE_XENSTORE, dom));
xc_hvm_param_set(xch, domid, HVM_PARAM_BUFIOREQ_PFN,
- special_pfn(SPECIALPAGE_BUFIOREQ));
+ special_pfn(SPECIALPAGE_BUFIOREQ, dom));
xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_PFN,
- special_pfn(SPECIALPAGE_IOREQ));
+ special_pfn(SPECIALPAGE_IOREQ, dom));
xc_hvm_param_set(xch, domid, HVM_PARAM_CONSOLE_PFN,
- special_pfn(SPECIALPAGE_CONSOLE));
+ special_pfn(SPECIALPAGE_CONSOLE, dom));
xc_hvm_param_set(xch, domid, HVM_PARAM_PAGING_RING_PFN,
- special_pfn(SPECIALPAGE_PAGING));
+ special_pfn(SPECIALPAGE_PAGING, dom));
xc_hvm_param_set(xch, domid, HVM_PARAM_MONITOR_RING_PFN,
- special_pfn(SPECIALPAGE_ACCESS));
+ special_pfn(SPECIALPAGE_ACCESS, dom));
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
- special_pfn(SPECIALPAGE_SHARING));
+ special_pfn(SPECIALPAGE_SHARING, dom));
if ( dom->emulation )
{
@@ -567,7 +579,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
* server will use the IOREQ and BUFIOREQ special
[Xen-devel] [PATCH v2 13/22] lib{xc/xl}: allow creating domains without emulated devices.
Allow device_model_version to be set to "none" in order to request the
creation of a HVM guest without emulated devices. This disables the VGA
and MMIO memory holes and the ioreq server pages.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/include/xc_dom.h | 1 +
tools/libxc/xc_dom_x86.c | 71 +---
tools/libxl/libxl.c | 7 ++---
tools/libxl/libxl_create.c | 16 ++
tools/libxl/libxl_dom.c | 43 +--
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 ++
7 files changed, 90 insertions(+), 51 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 68b052c..7086f6e 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -194,6 +194,7 @@ struct xc_dom_image {
xen_pfn_t mmio_size;
xen_pfn_t lowmem_end;
xen_pfn_t highmem_end;
+bool emulation;
/* Extra ACPI tables passed to HVMLOADER */
struct xc_hvm_firmware_module acpi_module;
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 6573b94..336eab4 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -520,12 +520,15 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
xc_interface *xch = dom->xch;
-if ( (hvm_info_page = xc_map_foreign_range(
- xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
- HVM_INFO_PFN)) == NULL )
-goto error_out;
-build_hvm_info(hvm_info_page, dom);
-munmap(hvm_info_page, PAGE_SIZE);
+if ( dom->emulation )
+{
+if ( (hvm_info_page = xc_map_foreign_range(
+ xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ HVM_INFO_PFN)) == NULL )
+goto error_out;
+build_hvm_info(hvm_info_page, dom);
+munmap(hvm_info_page, PAGE_SIZE);
+}
/* Allocate and clear special pages. */
for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
@@ -557,30 +560,33 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
special_pfn(SPECIALPAGE_SHARING));
-/*
- * Allocate and clear additional ioreq server pages. The default
- * server will use the IOREQ and BUFIOREQ special pages above.
- */
-for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
-ioreq_server_array[i] = ioreq_server_pfn(i);
-
-rc = xc_domain_populate_physmap_exact(xch, domid, NR_IOREQ_SERVER_PAGES, 0,
- 0, ioreq_server_array);
-if ( rc != 0 )
+if ( dom->emulation )
{
-DOMPRINTF("Could not allocate ioreq server pages.");
-goto error_out;
-}
+/*
+ * Allocate and clear additional ioreq server pages. The default
+ * server will use the IOREQ and BUFIOREQ special pages above.
+ */
+for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
+ioreq_server_array[i] = ioreq_server_pfn(i);
-if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
- NR_IOREQ_SERVER_PAGES) )
+rc = xc_domain_populate_physmap_exact(xch, domid,
NR_IOREQ_SERVER_PAGES, 0,
+ 0, ioreq_server_array);
+if ( rc != 0 )
+{
+DOMPRINTF("Could not allocate ioreq server pages.");
goto error_out;
+}
-/* Tell the domain where the pages are and how many there are */
-xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
- ioreq_server_pfn(0));
-xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
- NR_IOREQ_SERVER_PAGES);
+if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
+ NR_IOREQ_SERVER_PAGES) )
+goto error_out;
+
+/* Tell the domain where the pages are and how many there are */
+xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
+ ioreq_server_pfn(0));
+xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+ NR_IOREQ_SERVER_PAGES);
+}
/*
* Identity-map page table is required for running with CR0.PG=0 when
@@ -1228,7 +1234,8 @@ static int meminit_hvm(struct xc_dom_image *dom)
* allocated is pointless.
*/
if ( claim_enabled ) {
-rc = xc_domain_claim_pages(xch, domid, target_pages - VGA_HOLE_SIZE);
+rc = xc_domain_claim_pages(xch, domid, target_pages -
+ dom->emulation ? VGA_HOLE_SIZE : 0);
if ( rc != 0 )
{
DOMPRINTF("Could not allocate memory for HVM guest as we cannot
claim memory!");
@@ -1244,7 +1251,8 @@ static int meminit_hvm(struct xc_dom_image *dom)
[Xen-devel] [PATCH v2 16/22] xenconsole: try to attach to PV console if HVM fails
HVM guests have always used the emulated serial console by default, but if
the emulated serial pty cannot be fetched from xenstore try to use the PV
console instead.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/console/client/main.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index f4c783b..c92553e 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -279,7 +279,7 @@ int main(int argc, char **argv)
{ 0 },
};
- char *dom_path = NULL, *path = NULL;
+ char *dom_path = NULL, *path = NULL, *test = NULL;
int spty, xsfd;
struct xs_handle *xs;
char *end;
@@ -357,9 +357,14 @@ int main(int argc, char **argv)
path = malloc(strlen(dom_path) + strlen("/device/console/0/tty") + 5);
if (path == NULL)
err(ENOMEM, "malloc");
- if (type == CONSOLE_SERIAL)
+ if (type == CONSOLE_SERIAL) {
snprintf(path, strlen(dom_path) + strlen("/serial/0/tty") + 5,
"%s/serial/%d/tty", dom_path, num);
- else {
+ test = xs_read(xs, XBT_NULL, path, NULL);
+ free(test);
+ if (test == NULL)
+ goto pv_console;
+ } else {
+pv_console:
if (num == 0)
snprintf(path, strlen(dom_path) +
strlen("/console/tty") + 1, "%s/console/tty", dom_path);
else
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 10/22] libxc: remove dead HVM building code
Remove xc_hvm_build_x86.c and xc_hvm_build_arm.c since xc_hvm_build is not
longer used in order to create HVM guests.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/Makefile | 2 -
tools/libxc/include/xenguest.h| 44 ---
tools/libxc/xc_hvm_build_arm.c| 49 ---
tools/libxc/xc_hvm_build_x86.c| 807 --
tools/libxc/xg_private.c | 9 -
tools/python/xen/lowlevel/xc/xc.c | 81
6 files changed, 992 deletions(-)
delete mode 100644 tools/libxc/xc_hvm_build_arm.c
delete mode 100644 tools/libxc/xc_hvm_build_x86.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 48fc473..a143c0f 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -94,9 +94,7 @@ GUEST_SRCS-y += xc_dom_compat_linux.c
GUEST_SRCS-$(CONFIG_X86) += xc_dom_x86.c
GUEST_SRCS-$(CONFIG_X86) += xc_cpuid_x86.c
-GUEST_SRCS-$(CONFIG_X86) += xc_hvm_build_x86.c
GUEST_SRCS-$(CONFIG_ARM) += xc_dom_arm.c
-GUEST_SRCS-$(CONFIG_ARM) += xc_hvm_build_arm.c
ifeq ($(CONFIG_LIBXC_MINIOS),y)
GUEST_SRCS-y += xc_dom_decompress_unsafe.c
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 7581263..d96bf7d 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -233,50 +233,6 @@ struct xc_hvm_firmware_module {
uint64_t guest_addr_out;
};
-struct xc_hvm_build_args {
-uint64_t mem_size; /* Memory size in bytes. */
-uint64_t mem_target; /* Memory target in bytes. */
-uint64_t mmio_size; /* Size of the MMIO hole in bytes. */
-const char *image_file_name; /* File name of the image to load. */
-
-/* Extra ACPI tables passed to HVMLOADER */
-struct xc_hvm_firmware_module acpi_module;
-
-/* Extra SMBIOS structures passed to HVMLOADER */
-struct xc_hvm_firmware_module smbios_module;
-/* Whether to use claim hypercall (1 - enable, 0 - disable). */
-int claim_enabled;
-
-/* vNUMA information*/
-xen_vmemrange_t *vmemranges;
-unsigned int nr_vmemranges;
-unsigned int *vnode_to_pnode;
-unsigned int nr_vnodes;
-
-/* Out parameters */
-uint64_t lowmem_end;
-uint64_t highmem_end;
-uint64_t mmio_start;
-};
-
-/**
- * Build a HVM domain.
- * @parm xch libxc context handle.
- * @parm domiddomain ID for the new domain.
- * @parm hvm_args parameters for the new domain.
- *
- * The memory size and image file parameters are required, the rest
- * are optional.
- */
-int xc_hvm_build(xc_interface *xch, uint32_t domid,
- struct xc_hvm_build_args *hvm_args);
-
-int xc_hvm_build_target_mem(xc_interface *xch,
-uint32_t domid,
-int memsize,
-int target,
-const char *image_name);
-
/*
* Sets *lockfd to -1.
* Has deallocated everything even on error.
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
deleted file mode 100644
index ff66689..000
--- a/tools/libxc/xc_hvm_build_arm.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/**
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
- *
- * Copyright (c) 2011, Citrix Systems
- */
-
-#include
-#include
-#include
-#include
-
-int xc_hvm_build(xc_interface *xch, uint32_t domid,
- struct xc_hvm_build_args *hvm_args)
-{
-errno = ENOSYS;
-return -1;
-}
-
-int xc_hvm_build_target_mem(xc_interface *xch,
- uint32_t domid,
- int memsize,
- int target,
- const char *image_name)
-{
-errno = ENOSYS;
-return -1;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
deleted file mode 100644
index 7195bdb..000
--- a/tools/libxc/xc_hvm_build_x86.c
+++ /dev/null
@@ -1,807 +0,0 @@
-/**
- * xc_hvm_build.c
- *
- * This librar
[Xen-devel] [PATCH v2 19/22] libxc/xen: introduce HVM_PARAM_FIRST_FREE_PFN
This HVM parameter returns the first free pfn after all the special pages.
It can be used by guests to figure out the first free memory address after
the kernel, ramdisk and special pages. This is interesting for compatibility
reasons in case more special pages are later added, older guests can still
use this parameter to figure out the first free address, ignoring newly
added special pages.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
---
tools/libxc/xc_dom_x86.c| 2 ++
xen/arch/x86/hvm/hvm.c | 1 +
xen/include/public/hvm/params.h | 5 -
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 41ff7a4..74c3819 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -573,6 +573,8 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
special_pfn(SPECIALPAGE_ACCESS, dom));
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
special_pfn(SPECIALPAGE_SHARING, dom));
+xc_hvm_param_set(xch, domid, HVM_PARAM_FIRST_FREE_PFN,
+ special_pfn(NR_SPECIAL_PAGES, dom));
if ( dom->cmdline )
{
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 945f42e..b7b1300 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5901,6 +5901,7 @@ static int hvm_allow_get_param(struct domain *d,
case HVM_PARAM_CONSOLE_PFN:
case HVM_PARAM_CONSOLE_EVTCHN:
case HVM_PARAM_CMDLINE_PFN:
+case HVM_PARAM_FIRST_FREE_PFN:
break;
/*
* The following parameters must not be read by the guest
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index b7f8839..47e38a8 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -190,6 +190,9 @@
/* PFN of the command line. */
#define HVM_PARAM_CMDLINE_PFN 35
-#define HVM_NR_PARAMS 36
+/* First free PFN after the special pages. */
+#define HVM_PARAM_FIRST_FREE_PFN 36
+
+#define HVM_NR_PARAMS 37
#endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 15/22] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and VCPUOP_is_up hypercalls from HVM guests. Signed-off-by: Roger Pau Monné Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/hvm/hvm.c | 8 1 file changed, 8 insertions(+) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 8a9c9df..7aefcf8 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4791,6 +4791,10 @@ static long hvm_vcpu_op( case VCPUOP_stop_singleshot_timer: case VCPUOP_register_vcpu_info: case VCPUOP_register_vcpu_time_memory_area: +case VCPUOP_initialise: +case VCPUOP_up: +case VCPUOP_down: +case VCPUOP_is_up: rc = do_vcpu_op(cmd, vcpuid, arg); break; default: @@ -4849,6 +4853,10 @@ static long hvm_vcpu_op_compat32( case VCPUOP_stop_singleshot_timer: case VCPUOP_register_vcpu_info: case VCPUOP_register_vcpu_time_memory_area: +case VCPUOP_initialise: +case VCPUOP_up: +case VCPUOP_down: +case VCPUOP_is_up: rc = compat_vcpu_op(cmd, vcpuid, arg); break; default: -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 20/22] libxc/xen: introduce HVM_PARAM_MODLIST_PFN
This HVM parameter is used to pass a list of loaded modules to the guest.
Right now the number of loaded modules is limited to 1 by the current
implementation, but this interface allows passing more than one module.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
tools/libxc/xc_dom_x86.c| 24 +++-
xen/arch/x86/hvm/hvm.c | 1 +
xen/include/public/hvm/params.h | 23 ++-
3 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 74c3819..71b353e 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -58,7 +58,8 @@
#define SPECIALPAGE_IDENT_PT 6
#define SPECIALPAGE_CONSOLE 7
#define SPECIALPAGE_CMDLINE 8
-#define NR_SPECIAL_PAGES 9
+#define SPECIALPAGE_MODLIST 9
+#define NR_SPECIAL_PAGES 10
#define LAST_SPECIAL_PFN 0xff000u
#define NR_IOREQ_SERVER_PAGES 8
@@ -533,6 +534,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
xc_interface *xch = dom->xch;
char *cmdline;
+uint64_t *modlist;
if ( dom->emulation )
{
@@ -621,6 +623,26 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
NR_IOREQ_SERVER_PAGES);
}
+if ( dom->ramdisk_blob )
+{
+modlist = xc_map_foreign_range(
+ xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ special_pfn(SPECIALPAGE_MODLIST, dom));
+if ( modlist == NULL ) {
+DOMPRINTF("Unable to map module list page");
+goto error_out;
+}
+
+/* This is currently limited to only one module. */
+modlist[0] = dom->ramdisk_seg.vstart - dom->parms.virt_base;
+modlist[1] = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+modlist[2] = 0;
+modlist[3] = 0;
+munmap(modlist, PAGE_SIZE);
+xc_hvm_param_set(xch, domid, HVM_PARAM_MODLIST_PFN,
+ special_pfn(SPECIALPAGE_MODLIST, dom));
+}
+
/*
* Identity-map page table is required for running with CR0.PG=0 when
* using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b7b1300..293e740 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5902,6 +5902,7 @@ static int hvm_allow_get_param(struct domain *d,
case HVM_PARAM_CONSOLE_EVTCHN:
case HVM_PARAM_CMDLINE_PFN:
case HVM_PARAM_FIRST_FREE_PFN:
+case HVM_PARAM_MODLIST_PFN:
break;
/*
* The following parameters must not be read by the guest
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 47e38a8..86cc15b 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -193,6 +193,27 @@
/* First free PFN after the special pages. */
#define HVM_PARAM_FIRST_FREE_PFN 36
-#define HVM_NR_PARAMS 37
+/*
+ * List of modules passed to the kernel.
+ *
+ * The PFN returned by this HVM_PARAM points to a page that contains an
+ * array of unsigned 64bit integers encoded in little endian.
+ *
+ * The first integer contains the address where the module has been loaded,
+ * while the second contains the size of the module in bytes. The last element
+ * in the array is a module with address 0 and length 0:
+ *
+ * module[0] =
+ * module[1] =
+ * [...]
+ * module[N/2] =
+ * module[N/2+1] =
+ * [...]
+ * module[M] = 0
+ * module[M+1] = 0
+ */
+#define HVM_PARAM_MODLIST_PFN 37
+
+#define HVM_NR_PARAMS 38
#endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 18/22] libxc/xen: introduce HVM_PARAM_CMDLINE_PFN
This HVM parameter returns a PFN that contains the address of the memory
page where the guest command line has been placed.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
---
tools/libxc/xc_dom_x86.c| 21 -
xen/arch/x86/hvm/hvm.c | 1 +
xen/include/public/hvm/params.h | 5 -
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 1195400..41ff7a4 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -57,7 +57,8 @@
#define SPECIALPAGE_IOREQ5
#define SPECIALPAGE_IDENT_PT 6
#define SPECIALPAGE_CONSOLE 7
-#define NR_SPECIAL_PAGES 8
+#define SPECIALPAGE_CMDLINE 8
+#define NR_SPECIAL_PAGES 9
#define LAST_SPECIAL_PFN 0xff000u
#define NR_IOREQ_SERVER_PAGES 8
@@ -531,6 +532,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xen_pfn_t special_array[NR_SPECIAL_PAGES];
xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
xc_interface *xch = dom->xch;
+char *cmdline;
if ( dom->emulation )
{
@@ -572,6 +574,23 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
special_pfn(SPECIALPAGE_SHARING, dom));
+if ( dom->cmdline )
+{
+cmdline = xc_map_foreign_range(
+ xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ special_pfn(SPECIALPAGE_CMDLINE, dom));
+if ( cmdline == NULL ) {
+DOMPRINTF("Unable to map command line page");
+goto error_out;
+}
+
+strncpy(cmdline, dom->cmdline, MAX_GUEST_CMDLINE);
+cmdline[MAX_GUEST_CMDLINE - 1] = '\0';
+munmap(cmdline, PAGE_SIZE);
+xc_hvm_param_set(xch, domid, HVM_PARAM_CMDLINE_PFN,
+ special_pfn(SPECIALPAGE_CMDLINE, dom));
+}
+
if ( dom->emulation )
{
/*
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7aefcf8..945f42e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5900,6 +5900,7 @@ static int hvm_allow_get_param(struct domain *d,
case HVM_PARAM_STORE_EVTCHN:
case HVM_PARAM_CONSOLE_PFN:
case HVM_PARAM_CONSOLE_EVTCHN:
+case HVM_PARAM_CMDLINE_PFN:
break;
/*
* The following parameters must not be read by the guest
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 7c73089..b7f8839 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -187,6 +187,9 @@
/* Location of the VM Generation ID in guest physical address space. */
#define HVM_PARAM_VM_GENERATION_ID_ADDR 34
-#define HVM_NR_PARAMS 35
+/* PFN of the command line. */
+#define HVM_PARAM_CMDLINE_PFN 35
+
+#define HVM_NR_PARAMS 36
#endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 12/22] elfnotes: intorduce a new PHYS_ENTRY elfnote
This new elfnote contains the 32bit entry point into the kernel. Xen will
use this entry point in order to launch the guest kernel in 32bit protected
mode with paging disabled.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xcutils/readnotes.c | 3 +++
xen/common/libelf/libelf-dominfo.c | 4
xen/include/public/elfnote.h | 11 ++-
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/xcutils/readnotes.c b/tools/xcutils/readnotes.c
index 5fa445e..863ea5f 100644
--- a/tools/xcutils/readnotes.c
+++ b/tools/xcutils/readnotes.c
@@ -159,6 +159,9 @@ static unsigned print_notes(struct elf_binary *elf,
ELF_HANDLE_DECL(elf_note) st
case XEN_ELFNOTE_L1_MFN_VALID:
print_l1_mfn_valid_note("L1_MFN_VALID", elf , note);
break;
+ case XEN_ELFNOTE_PHYS_ENTRY:
+ print_numeric_note("PHYS_ENTRY", elf , note);
+ break;
default:
printf("unknown note type %#x\n",
(unsigned)elf_uval(elf, note, type));
diff --git a/xen/common/libelf/libelf-dominfo.c
b/xen/common/libelf/libelf-dominfo.c
index 0771323..78d75ad 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -120,6 +120,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
[XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
[XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
[XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
+[XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
};
/* *INDENT-ON* */
@@ -213,6 +214,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
elf, note, sizeof(*parms->f_supported), i);
break;
+case XEN_ELFNOTE_PHYS32_ENTRY:
+parms->phys_entry = val;
+break;
}
return 0;
}
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 3824a94..e6fc596 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -200,9 +200,18 @@
#define XEN_ELFNOTE_SUPPORTED_FEATURES 17
/*
+ * Physical entry point into the kernel.
+ *
+ * 32bit entry point into the kernel. Xen will use this entry point
+ * in order to launch the guest kernel in 32bit protected mode
+ * with paging disabled.
+ */
+#define XEN_ELFNOTE_PHYS32_ENTRY 18
+
+/*
* The number of the highest elfnote defined.
*/
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_SUPPORTED_FEATURES
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
/*
* System information exported through crash notes.
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 21/22] libxl: set correct nic type for HVM guests without a device model
If there's no device model running nic type is always LIBXL_NIC_TYPE_VIF. Signed-off-by: Roger Pau Monné Cc: Ian Jackson Cc: Stefano Stabellini Cc: Ian Campbell Cc: Wei Liu --- tools/libxl/libxl_create.c | 5 + 1 file changed, 5 insertions(+) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index a00eda9..fb8b97b 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -955,6 +955,11 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__device_nic_setdefault(gc, &d_config->nics[i], domid); if (ret) goto error_out; +/* HVM guests without a device model only have PV nics. */ +if (d_config->b_info.device_model_version == +LIBXL_DEVICE_MODEL_VERSION_NONE) +d_config->nics[i].nictype = LIBXL_NIC_TYPE_VIF; + if (d_config->nics[i].devid > last_devid) last_devid = d_config->nics[i].devid; } -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 14/22] xen: allow HVM guests to use XENMEM_memory_map
Enable this hypercall for HVM guests in order to fetch the e820 memory
map in the absence of an emulated BIOS. The memory map is populated and
notified to Xen in arch_setup_meminit_hvm.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
---
tools/libxc/xc_dom_x86.c | 29 -
xen/arch/x86/hvm/hvm.c | 2 --
xen/arch/x86/mm.c| 6 --
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 336eab4..45b1f03 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -1113,6 +1113,7 @@ static int check_mmio_hole(uint64_t start, uint64_t
memsize,
return 1;
}
+#define MAX_E820_ENTRIES128
static int meminit_hvm(struct xc_dom_image *dom)
{
unsigned long i, vmemid, nr_pages = dom->total_pages;
@@ -1133,6 +1134,8 @@ static int meminit_hvm(struct xc_dom_image *dom)
unsigned int nr_vmemranges, nr_vnodes;
xc_interface *xch = dom->xch;
uint32_t domid = dom->guest_domid;
+struct e820entry entries[MAX_E820_ENTRIES];
+int e820_index = 0;
if ( nr_pages > target_pages )
memflags |= XENMEMF_populate_on_demand;
@@ -1183,6 +1186,13 @@ static int meminit_hvm(struct xc_dom_image *dom)
vnode_to_pnode = dom->vnode_to_pnode;
}
+/* Add one additional memory range to account for the VGA hole */
+if ( (nr_vmemranges + (dom->emulation ? 1 : 0)) > MAX_E820_ENTRIES )
+{
+DOMPRINTF("Too many memory ranges");
+goto error_out;
+}
+
total_pages = 0;
p2m_size = 0;
for ( i = 0; i < nr_vmemranges; i++ )
@@ -1271,9 +1281,13 @@ static int meminit_hvm(struct xc_dom_image *dom)
* Under 2MB mode, we allocate pages in batches of no more than 8MB to
* ensure that we can be preempted and hence dom0 remains responsive.
*/
-if ( dom->emulation )
+if ( dom->emulation ) {
rc = xc_domain_populate_physmap_exact(
xch, domid, 0xa0, 0, memflags, &dom->p2m_host[0x00]);
+entries[e820_index].addr = 0;
+entries[e820_index].size = 0xa0 << PAGE_SHIFT;
+entries[e820_index++].type = E820_RAM;
+}
stat_normal_pages = 0;
for ( vmemid = 0; vmemid < nr_vmemranges; vmemid++ )
@@ -1300,6 +1314,12 @@ static int meminit_hvm(struct xc_dom_image *dom)
else
cur_pages = vmemranges[vmemid].start >> PAGE_SHIFT;
+/* Build an e820 map. */
+entries[e820_index].addr = cur_pages << PAGE_SHIFT;
+entries[e820_index].size = vmemranges[vmemid].end -
+ entries[e820_index].addr;
+entries[e820_index++].type = E820_RAM;
+
while ( (rc == 0) && (end_pages > cur_pages) )
{
/* Clip count to maximum 1GB extent. */
@@ -1417,6 +1437,13 @@ static int meminit_hvm(struct xc_dom_image *dom)
DPRINTF(" 2MB PAGES: 0x%016lx\n", stat_2mb_pages);
DPRINTF(" 1GB PAGES: 0x%016lx\n", stat_1gb_pages);
+rc = xc_domain_set_memory_map(xch, domid, entries, e820_index);
+if ( rc != 0 )
+{
+DOMPRINTF("unable to set memory map.");
+goto error_out;
+}
+
rc = 0;
goto out;
error_out:
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 66f95b2..8a9c9df 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4748,7 +4748,6 @@ static long hvm_memory_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( cmd & MEMOP_CMD_MASK )
{
-case XENMEM_memory_map:
case XENMEM_machine_memory_map:
case XENMEM_machphys_mapping:
return -ENOSYS;
@@ -4824,7 +4823,6 @@ static long hvm_memory_op_compat32(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( cmd & MEMOP_CMD_MASK )
{
-case XENMEM_memory_map:
case XENMEM_machine_memory_map:
case XENMEM_machphys_mapping:
return -ENOSYS;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index fd151c6..92eccd0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4717,12 +4717,6 @@ long arch_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
return rc;
}
-if ( is_hvm_domain(d) )
-{
-rcu_unlock_domain(d);
-return -EPERM;
-}
-
e820 = xmalloc_array(e820entry_t, fmap.map.nr_entries);
if ( e820 == NULL )
{
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 22/22] lib{xc/xl}: allow the creation of HVM domains with a kernel
Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
builder now uses the PV xc_dom_* set of functions this kernel will be parsed
and loaded inside the guest like on PV, but the container is a pure HVM
guest.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Only xc_dom_elfloader has been switched in order to use hvm-3.0-x86_32,
other loaders need to be adapted also.
---
tools/libxc/xc_dom_elfloader.c | 4
tools/libxl/libxl_dom.c| 18 ++
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 6ce1062..2f05015 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -57,6 +57,10 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
{
uint64_t machine = elf_uval(elf, elf->ehdr, e_machine);
+if ( dom->container_type == XC_DOM_HVM_CONTAINER &&
+ dom->parms.phys_entry != UNSET_ADDR )
+return "hvm-3.0-x86_32";
+
switch ( machine )
{
case EM_386:
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d209f67..d3d64d2 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -900,10 +900,21 @@ static int libxl__domain_firmware(libxl__gc *gc,
}
}
-rc = xc_dom_kernel_file(dom, libxl__abs_path(gc, firmware,
+if (info->kernel != NULL &&
+info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) {
+/* Try to load a kernel instead of the firmware. */
+rc = xc_dom_kernel_file(dom, info->kernel);
+if (rc == 0 && info->ramdisk != NULL)
+rc = xc_dom_ramdisk_file(dom, info->ramdisk);
+dom->emulation = false;
+} else {
+rc = xc_dom_kernel_file(dom, libxl__abs_path(gc, firmware,
libxl__xenfirmwaredir_path()));
+dom->emulation = true;
+}
+
if (rc != 0) {
-LOGE(ERROR, "xc_dom_kernel_file failed");
+LOGE(ERROR, "xc_dom_{kernel_file/ramdisk_file} failed");
goto out;
}
@@ -960,7 +971,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
xc_dom_loginit(ctx->xch);
-dom = xc_dom_allocate(ctx->xch, NULL, NULL);
+dom = xc_dom_allocate(ctx->xch, info->cmdline, NULL);
if (!dom) {
LOGE(ERROR, "xc_dom_allocate failed");
goto out;
@@ -1003,7 +1014,6 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
dom->lowmem_end = lowmem_end;
dom->highmem_end = highmem_end;
dom->mmio_start = mmio_start;
-dom->emulation = true;
if (info->num_vnuma_nodes != 0) {
int i;
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] osstest: install libnl3 packages
Install the libnl3 packages needed by the remus code. Those are available on
both Wheezy and Jessie, although the Wheezy ones are too old.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Shriram Rajagopalan
Cc: Yang Hongyang
---
ts-xen-build-prep | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 9a3b523..034377e 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -206,14 +206,8 @@ sub prep () {
autoconf automake libtool xsltproc
libxml2-utils libxml2-dev
libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
- ccache nasm checkpolicy);
+ ccache nasm checkpolicy libnl-3-dev libnl-route-3-dev);
-if ($ho->{Suite} =~ m/wheezy|squeeze|lenny/) {
- push(@packages, "libnl-dev");
-} else {
- # jessie (>jessie?)
- push(@packages, "libnl-route-3-dev");
-}
target_install_packages($ho, @packages);
target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
# workaround for Debian #595728
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/13] arm: Allow the user to specify the GIC version
On 01/07/15 15:50, Ian Campbell wrote: > On Wed, 2015-07-01 at 15:37 +0100, Julien Grall wrote: >>> AFIACT the default is "offer the guest the hardware's native version". >> >> This is true when the domain is firstly created. But this will be >> confusing if the user decide to migrate the guest to a platform where >> the native GIC is different. >> >> This is a valid use-case, though we don't support migration yet, and the >> guest will expect to get the same virtual GIC (the IRQ controller driver >> can't be changed). > > I think an option "native" which is documented to be latching on the > host the guest is started on is absolutely fine, and avoids needing to > faff around turning default into native at the interface and/or parsing > stage. I wasn't planning to introduce another option. The question was about the naming about the default option i.e either "native" or "default". For both naming with still have to translate the xl option into an hypervisor value (i.e XEN_DOMCTL_CONFIG_GIC_*). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy
Hi, On 01/07/15 15:39, George Dunlap wrote: > Then make the meaning of the flags as follows: > * for pci devices: > - RDM_RELAXED flag SET: ignore conflicts in set_identity_p2m_entry() > - RDM_RELAXED flag CLEAR: error on conflicts in set_identity_p2m_entry() > * for dt devices: > - Ignore this flag entirely > > If Julien really wants we could error on RDM_RELAXED being set; but I > don't think that's necessary. I was confused when I suggested this. After speaking with George IRL, I'm fine with his solution. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Increase device model startup timeout to 1min.
On Tue, 30 Jun 2015, Ian Jackson wrote: > > > * The number and nature of parallel operations done in the stress > > > test is unreasonable for the provided hardware: > > > => the timeout is fine > > > > I don't know if it is our place to make this call. Should we really be > > deciding what is considered "reasonable"? I think not. Defining what is > > reasonable and policies that match it is not a route I think we should > > take in libxl. > > Nevertheless if we are defining timeouts we are implicitly setting > some parameters which imply that certain configurations are > unreasonable. Hopefully all such configurations are absurd. > > If what you mean is that our bounds of `reasonable' should be very > wide, then I agree. If anyone could reasonably expect it to work, > then that is fine. Certainly we should refrain fromk subjective > judgements. OK. How do you measure reasonable for this case? What I actually mean to ask is how do you suggest we proceed on this problem? Of course it would be nice if we knew exactly why this is happening, but the issue only happens once every 2-3 tempest runs, each of them takes about 1 hour. Tempest executes about 1300 tests for each run, some of them in parallel. We haven't taken the time to read all the tests run by tempest so we don't know exactly what they do. We don't really know the environment that causes the failure. Reading all the tests is not an option. We could try adding more tracing to the system, but given the type of error, if we do we are not likely to reproduce the error at all, or maybe reproduce something different. Given the state of things, I suggest we make sure that increasing the timeout actually fixes/works-around the problem. I would also like to see some empirical measurements that tell us by how much we should increase the timeout. Is 1 minute actually enough? I would not go as far as asking to figure out what the real cause of the problem is, because there is no way to estimate how long is going to take or even how to do that. And in the meantime we still have spurious failures in the OpenStack CI-loop. Alternatively we could carry the work around in the Xen package we build for the OpenStack CI-loop, leaving xen-unstable "unfixed", but I think that would be less desirable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH] Email reports: Use osstest-output@lists.xenproject
No longer send reports, or copies, to named individuals. Instead, send all output to the new osstest-output list (CC other appropriate lists). After this patch goes live, people interested in bisection progress emails will find them in the new list. (There are a lot of these.) (Configurations for `adhoc' and `play' runs remain unchanged and still have a tendency to refer to my personal address @citrix.) Deployment notes: Keir and Stefano will no longer receive automatic CCs of certain reports, and should subscribe to the osstest-output list, with appropriate filtering, if they care. To make this work with my own personal configuration, I need to: - subscribe myself @citrix to osstest-output - subscribe my chiark mail-to-news gateway to osstest-output - after mail starts flowing, set up appropriate filters @citrix Signed-off-by: Ian Jackson CC: k...@xen.org CC: stefano.stabell...@eu.citrix.com CC: Lars Kurth --- daily-cron-email-osstest |2 +- daily-cron-email-real |2 +- daily-cron-email-real--rumpuserxen|2 +- daily-cron-email-real-bisectcomplete |4 +--- daily-cron-email-real-bisectcomplete--rumpuserxen |2 +- daily-cron-email-real-bisectdone |2 +- daily-cron-email-real-bisectrun |2 +- 7 files changed, 7 insertions(+), 9 deletions(-) diff --git a/daily-cron-email-osstest b/daily-cron-email-osstest index 8a9fac4..1eb6909 100644 --- a/daily-cron-email-osstest +++ b/daily-cron-email-osstest @@ -1 +1 @@ -To: ian.jack...@eu.citrix.com,ian.campb...@eu.citrix.com +To: osstest-out...@lists.xenproject.org diff --git a/daily-cron-email-real b/daily-cron-email-real index e43d780..2abc1a2 100644 --- a/daily-cron-email-real +++ b/daily-cron-email-real @@ -1,2 +1,2 @@ To: xen-de...@lists.xensource.com -Cc: ian.jack...@eu.citrix.com +Cc: osstest-out...@lists.xenproject.org diff --git a/daily-cron-email-real--rumpuserxen b/daily-cron-email-real--rumpuserxen index a9166a0..dbb8bcd 100644 --- a/daily-cron-email-real--rumpuserxen +++ b/daily-cron-email-real--rumpuserxen @@ -1,3 +1,3 @@ To: xen-de...@lists.xensource.com, rumpkernel-bui...@freelists.org -Cc: ian.jack...@eu.citrix.com +Cc: osstest-out...@lists.xenproject.org diff --git a/daily-cron-email-real-bisectcomplete b/daily-cron-email-real-bisectcomplete index 18ae6ad..2abc1a2 100644 --- a/daily-cron-email-real-bisectcomplete +++ b/daily-cron-email-real-bisectcomplete @@ -1,4 +1,2 @@ To: xen-de...@lists.xensource.com -Cc: k...@xen.org, -stefano.stabell...@eu.citrix.com, -ian.jack...@eu.citrix.com +Cc: osstest-out...@lists.xenproject.org diff --git a/daily-cron-email-real-bisectcomplete--rumpuserxen b/daily-cron-email-real-bisectcomplete--rumpuserxen index a9166a0..dbb8bcd 100644 --- a/daily-cron-email-real-bisectcomplete--rumpuserxen +++ b/daily-cron-email-real-bisectcomplete--rumpuserxen @@ -1,3 +1,3 @@ To: xen-de...@lists.xensource.com, rumpkernel-bui...@freelists.org -Cc: ian.jack...@eu.citrix.com +Cc: osstest-out...@lists.xenproject.org diff --git a/daily-cron-email-real-bisectdone b/daily-cron-email-real-bisectdone index eef18cd..1eb6909 100644 --- a/daily-cron-email-real-bisectdone +++ b/daily-cron-email-real-bisectdone @@ -1 +1 @@ -To: list-a__chiark.users.ijackson.xen.cron.osst...@chiark.greenend.org.uk +To: osstest-out...@lists.xenproject.org diff --git a/daily-cron-email-real-bisectrun b/daily-cron-email-real-bisectrun index eef18cd..1eb6909 100644 --- a/daily-cron-email-real-bisectrun +++ b/daily-cron-email-real-bisectrun @@ -1 +1 @@ -To: list-a__chiark.users.ijackson.xen.cron.osst...@chiark.greenend.org.uk +To: osstest-out...@lists.xenproject.org -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2] mg-all-branch-statuses: Show how up to date each branch is
On Wed, 2015-07-01 at 15:35 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v2] mg-all-branch-statuses: Show how
> up to date each branch is"):
> > On Wed, 2015-07-01 at 14:37 +0100, Ian Jackson wrote:
> > > These -??-?? are quite visually noisy.
> >
> > Agreed, I did consider just omitting them. Or would you prefer
> > "Unknown"?
>
> It's not so much unknown as n/a.
Do you prefer the script to say "n/a" rather than nothing?
> > > And the ISO dates are not
> > > ideal for reading - how about printing a number of days ago instead ?
> >
> > I was a bit lazy and it was easier to get date(1) to give me a date from
> > shell. I'll see if I can get the number of days ago out of it by
> > extending the Perl.
>
> Ah. Number of days is easy:
[...]
Thanks.
> > > > linux-next2e0a48c9 0 219 -??-??
> > > > 2014-04-10
> > >
> > > I'm not sure what this means. 219 in #Tot would normally be a problem
> > > and `1stNew' is from 2014. But linux-next is not fast-forwarding.
> > > And there's allegedly no tip although I think maybe you mean there is
> > > no basis.
> >
> > Lack of quoting on the call to printf may have confused things due to
> > empty parameters.
>
> Ah.
>
> > Quoting things results in:
> >
> > linux-next2e0a48c90 219 -??-??
> > 2014-04-10
> >
> > Should basis say "None" in this case IYO?
>
> I think blank is fine but I don't mind None.
I went with blank for no-basis.
> > > > osstest 15d2dd50 0- -??-??
> > > > -??-??
> > >
> > > Is the lack of a Tip here a bug ?
> >
> > I think it (ap-fetch-version) is looking in my $HOME and not osstest's.
> > I would expect this to be correct if I ran it as osstest.
>
> So it broke ? Shouldn't the script bomb out ?
That would be quite annoying since osstest.git is a bit odd/special in
its desire to be in $HOME/testing.git which not everyone will have.
Perhaps if we were to decide this was to be a cron only thing (and not
an end user script) I should a) rename it to cr-* and b) make it fail in
this case instead.
If it is to remain an mg-* then I could make it say "Error!" perhaps?
> > > > xen-4.5-testing e3bd3cef e3bd3cef
> > >
> > > You could replace one copy of `e3bd3cef' with `same' or soemthing.
> >
> > Or "UpToDate" ?
>
> For example.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/13] arm: Allow the user to specify the GIC version
On Wed, 2015-07-01 at 15:37 +0100, Julien Grall wrote: > > AFIACT the default is "offer the guest the hardware's native version". > > This is true when the domain is firstly created. But this will be > confusing if the user decide to migrate the guest to a platform where > the native GIC is different. > > This is a valid use-case, though we don't support migration yet, and the > guest will expect to get the same virtual GIC (the IRQ controller driver > can't be changed). I think an option "native" which is documented to be latching on the host the guest is started on is absolutely fine, and avoids needing to faff around turning default into native at the interface and/or parsing stage. Upon migration the config should have been updated to reflect whatever decision Xen made when the guest was first started. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 04/22] libxc: introduce a domain loader for HVM guest firmware
Introduce a very simple (and dummy) domain loader to be used to load the
firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
executable the loader is fairly simple.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xc_dom.h | 8 ++
tools/libxc/xc_dom_hvmloader.c | 316 +
xen/include/xen/libelf.h | 1 +
4 files changed, 326 insertions(+)
create mode 100644 tools/libxc/xc_dom_hvmloader.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 153b79e..48fc473 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -87,6 +87,7 @@ GUEST_SRCS-y += xc_dom_core.c xc_dom_boot.c
GUEST_SRCS-y += xc_dom_elfloader.c
GUEST_SRCS-$(CONFIG_X86) += xc_dom_bzimageloader.c
GUEST_SRCS-$(CONFIG_X86) += xc_dom_decompress_lz4.c
+GUEST_SRCS-$(CONFIG_X86) += xc_dom_hvmloader.c
GUEST_SRCS-$(CONFIG_ARM) += xc_dom_armzimageloader.c
GUEST_SRCS-y += xc_dom_binloader.c
GUEST_SRCS-y += xc_dom_compat_linux.c
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index f7b5f0f..d61482c 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -15,6 +15,7 @@
*/
#include
+#include
#define INVALID_P2M_ENTRY ((xen_pfn_t)-1)
@@ -186,6 +187,13 @@ struct xc_dom_image {
XC_DOM_PV_CONTAINER,
XC_DOM_HVM_CONTAINER,
} container_type;
+
+/* HVM specific fields. */
+/* Extra ACPI tables passed to HVMLOADER */
+struct xc_hvm_firmware_module acpi_module;
+
+/* Extra SMBIOS structures passed to HVMLOADER */
+struct xc_hvm_firmware_module smbios_module;
};
/* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
new file mode 100644
index 000..b6270c9
--- /dev/null
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -0,0 +1,316 @@
+/*
+ * Xen domain builder -- HVM specific bits.
+ *
+ * Parse and load ELF firmware images for HVM domains.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "xg_private.h"
+#include "xc_dom.h"
+#include "xc_bitops.h"
+
+/* */
+/* parse elf binary */
+
+static elf_negerrnoval check_elf_kernel(struct xc_dom_image *dom, bool verbose)
+{
+if ( dom->kernel_blob == NULL )
+{
+if ( verbose )
+xc_dom_panic(dom->xch,
+ XC_INTERNAL_ERROR, "%s: no kernel image loaded",
+ __FUNCTION__);
+return -EINVAL;
+}
+
+if ( !elf_is_elfbinary(dom->kernel_blob, dom->kernel_size) )
+{
+if ( verbose )
+xc_dom_panic(dom->xch,
+ XC_INVALID_KERNEL, "%s: kernel is not an ELF image",
+ __FUNCTION__);
+return -EINVAL;
+}
+return 0;
+}
+
+static elf_negerrnoval xc_dom_probe_hvm_kernel(struct xc_dom_image *dom)
+{
+struct elf_binary elf;
+int rc;
+
+/* This loader is designed for HVM guest firmware. */
+if ( dom->container_type != XC_DOM_HVM_CONTAINER )
+return -EINVAL;
+
+rc = check_elf_kernel(dom, 0);
+if ( rc != 0 )
+return rc;
+
+rc = elf_init(&elf, dom->kernel_blob, dom->kernel_size);
+if ( rc != 0 )
+return rc;
+
+/*
+ * We need to check that there are no Xen ELFNOTES, or
+ * else we might be trying to load a PV kernel.
+ */
+elf_parse_binary(&elf);
+rc = elf_xen_parse(&elf, &dom->parms);
+if ( rc == 0 )
+return -EINVAL;
+
+return 0;
+}
+
+static elf_errorstatus xc_dom_parse_hvm_kernel(struct xc_dom_image *dom)
+/*
+ * This function sometimes returns -1 for error and sometimes
+ * an errno value. ?!?!
+ */
+{
+struct elf_binary *elf;
+elf_errorstatus rc;
+
+rc = check_elf_kernel(dom, 1);
+if ( rc != 0 )
+return rc;
+
+elf = xc_dom_malloc(dom, sizeof(*elf));
+if ( elf == NULL )
+return -1;
+dom->priva
[Xen-devel] [PATCH v2 09/22] libxl: switch HVM domain building to use xc_dom_* helpers
Now that we have all the code in place HVM domain building in libxl can be
switched to use the xc_dom_* family of functions, just like they are used in
order to build PV guests.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxl/libxl_dom.c | 225 +--
tools/libxl/libxl_internal.h | 2 +-
tools/libxl/libxl_vnuma.c| 12 ++-
3 files changed, 140 insertions(+), 99 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2bae277..6ce4115 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -609,6 +609,64 @@ static int set_vnuma_info(libxl__gc *gc, uint32_t domid,
return rc;
}
+static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
+ libxl_domain_build_info *info, libxl__domain_build_state *state,
+ struct xc_dom_image *dom)
+{
+libxl_ctx *ctx = libxl__gc_owner(gc);
+uint64_t mem_kb;
+int ret;
+
+if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
+LOGE(ERROR, "xc_dom_boot_xen_init failed");
+goto out;
+}
+#ifdef GUEST_RAM_BASE
+if ( (ret = xc_dom_rambase_init(dom, GUEST_RAM_BASE)) != 0 ) {
+LOGE(ERROR, "xc_dom_rambase failed");
+goto out;
+}
+#endif
+if ( (ret = xc_dom_parse_image(dom)) != 0 ) {
+LOGE(ERROR, "xc_dom_parse_image failed");
+goto out;
+}
+if ( (ret = libxl__arch_domain_init_hw_description(gc, info, state, dom))
!= 0 ) {
+LOGE(ERROR, "libxl__arch_domain_init_hw_description failed");
+goto out;
+}
+
+mem_kb = dom->container_type == XC_DOM_HVM_CONTAINER ?
+ (info->max_memkb - info->video_memkb) : info->target_memkb;
+if ( (ret = xc_dom_mem_init(dom, mem_kb / 1024)) != 0 ) {
+LOGE(ERROR, "xc_dom_mem_init failed");
+goto out;
+}
+if ( (ret = xc_dom_boot_mem_init(dom)) != 0 ) {
+LOGE(ERROR, "xc_dom_boot_mem_init failed");
+goto out;
+}
+if ( (ret = libxl__arch_domain_finalise_hw_description(gc, info, dom)) !=
0 ) {
+LOGE(ERROR, "libxl__arch_domain_finalise_hw_description failed");
+goto out;
+}
+if ( (ret = xc_dom_build_image(dom)) != 0 ) {
+LOGE(ERROR, "xc_dom_build_image failed");
+goto out;
+}
+if ( (ret = xc_dom_boot_image(dom)) != 0 ) {
+LOGE(ERROR, "xc_dom_boot_image failed");
+goto out;
+}
+if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+LOGE(ERROR, "xc_dom_gnttab_init failed");
+goto out;
+}
+
+out:
+return ret;
+}
+
int libxl__build_pv(libxl__gc *gc, uint32_t domid,
libxl_domain_build_info *info, libxl__domain_build_state *state)
{
@@ -699,48 +757,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
}
-if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
-LOGE(ERROR, "xc_dom_boot_xen_init failed");
-goto out;
-}
-#ifdef GUEST_RAM_BASE
-if ( (ret = xc_dom_rambase_init(dom, GUEST_RAM_BASE)) != 0 ) {
-LOGE(ERROR, "xc_dom_rambase failed");
-goto out;
-}
-#endif
-if ( (ret = xc_dom_parse_image(dom)) != 0 ) {
-LOGE(ERROR, "xc_dom_parse_image failed");
-goto out;
-}
-if ( (ret = libxl__arch_domain_init_hw_description(gc, info, state, dom))
!= 0 ) {
-LOGE(ERROR, "libxl__arch_domain_init_hw_description failed");
-goto out;
-}
-if ( (ret = xc_dom_mem_init(dom, info->target_memkb / 1024)) != 0 ) {
-LOGE(ERROR, "xc_dom_mem_init failed");
-goto out;
-}
-if ( (ret = xc_dom_boot_mem_init(dom)) != 0 ) {
-LOGE(ERROR, "xc_dom_boot_mem_init failed");
+ret = libxl__build_dom(gc, domid, info, state, dom);
+if (ret != 0)
goto out;
-}
-if ( (ret = libxl__arch_domain_finalise_hw_description(gc, info, dom)) !=
0 ) {
-LOGE(ERROR, "libxl__arch_domain_finalise_hw_description failed");
-goto out;
-}
-if ( (ret = xc_dom_build_image(dom)) != 0 ) {
-LOGE(ERROR, "xc_dom_build_image failed");
-goto out;
-}
-if ( (ret = xc_dom_boot_image(dom)) != 0 ) {
-LOGE(ERROR, "xc_dom_boot_image failed");
-goto out;
-}
-if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
-LOGE(ERROR, "xc_dom_gnttab_init failed");
-goto out;
-}
if (xc_dom_feature_translated(dom)) {
state->console_mfn = dom->console_pfn;
@@ -800,39 +819,39 @@ static int hvm_build_set_params(xc_interface *handle,
uint32_t domid,
static int hvm_build_set_xs_values(libxl__gc *gc,
uint32_t domid,
- struct xc_hvm_build_args *args)
+ struct xc_dom_image *dom)
{
char *path = NULL;
int ret = 0;
-if (args->smbios_module.guest
[Xen-devel] [PATCH v2 02/22] libxc: unify xc_dom_p2m_{host/guest}
Unify both functions into xc_dom_p2m. Should not introduce any functional
change.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Samuel Thibault
---
stubdom/grub/kexec.c | 4 ++--
tools/libxc/include/xc_dom.h | 14 ++
tools/libxc/xc_dom_boot.c | 10 +-
tools/libxc/xc_dom_compat_linux.c | 4 ++--
tools/libxc/xc_dom_x86.c | 32
tools/libxl/libxl_dom.c | 4 ++--
6 files changed, 29 insertions(+), 39 deletions(-)
diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 4c33b25..0b2f4f3 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -358,9 +358,9 @@ void kexec(void *kernel, long kernel_size, void *module,
long module_size, char
#ifdef __x86_64__
MMUEXT_PIN_L4_TABLE,
#endif
-xc_dom_p2m_host(dom, dom->pgtables_seg.pfn),
+xc_dom_p2m(dom, dom->pgtables_seg.pfn),
dom->guest_domid)) != 0 ) {
-grub_printf("pin_table(%lx) returned %d\n", xc_dom_p2m_host(dom,
+grub_printf("pin_table(%lx) returned %d\n", xc_dom_p2m(dom,
dom->pgtables_seg.pfn), rc);
errnum = ERR_BOOT_FAILURE;
goto out_remap;
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index a7d059a..ec9e293 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -376,19 +376,9 @@ static inline void *xc_dom_vaddr_to_ptr(struct
xc_dom_image *dom,
return ptr + offset;
}
-static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t
pfn)
+static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image *dom, xen_pfn_t pfn)
{
-if (dom->shadow_enabled)
-return pfn;
-if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
-return INVALID_MFN;
-return dom->p2m_host[pfn - dom->rambase_pfn];
-}
-
-static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
- xen_pfn_t pfn)
-{
-if (xc_dom_feature_translated(dom))
+if ( dom->shadow_enabled || xc_dom_feature_translated(dom) )
return pfn;
if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
return INVALID_MFN;
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index f82db2d..fda9e52 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -54,7 +54,7 @@ static int setup_hypercall_page(struct xc_dom_image *dom)
dom->parms.virt_hypercall, pfn);
domctl.cmd = XEN_DOMCTL_hypercall_init;
domctl.domain = dom->guest_domid;
-domctl.u.hypercall_init.gmfn = xc_dom_p2m_guest(dom, pfn);
+domctl.u.hypercall_init.gmfn = xc_dom_p2m(dom, pfn);
rc = do_domctl(dom->xch, &domctl);
if ( rc != 0 )
xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
@@ -84,7 +84,7 @@ static int clear_page(struct xc_dom_image *dom, xen_pfn_t pfn)
if ( pfn == 0 )
return 0;
-dst = xc_dom_p2m_host(dom, pfn);
+dst = xc_dom_p2m(dom, pfn);
DOMPRINTF("%s: pfn 0x%" PRIpfn ", mfn 0x%" PRIpfn "",
__FUNCTION__, pfn, dst);
rc = xc_clear_domain_page(dom->xch, dom->guest_domid, dst);
@@ -178,7 +178,7 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom,
xen_pfn_t pfn,
}
for ( i = 0; i < count; i++ )
-entries[i].mfn = xc_dom_p2m_host(dom, pfn + i);
+entries[i].mfn = xc_dom_p2m(dom, pfn + i);
ptr = xc_map_foreign_ranges(dom->xch, dom->guest_domid,
count << page_shift, PROT_READ | PROT_WRITE, 1 << page_shift,
@@ -435,8 +435,8 @@ int xc_dom_gnttab_init(struct xc_dom_image *dom)
dom->console_domid, dom->xenstore_domid);
} else {
return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
- xc_dom_p2m_host(dom, dom->console_pfn),
- xc_dom_p2m_host(dom, dom->xenstore_pfn),
+ xc_dom_p2m(dom, dom->console_pfn),
+ xc_dom_p2m(dom, dom->xenstore_pfn),
dom->console_domid, dom->xenstore_domid);
}
}
diff --git a/tools/libxc/xc_dom_compat_linux.c
b/tools/libxc/xc_dom_compat_linux.c
index 2c14a0f..acccde9 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -65,8 +65,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
if ( (rc = xc_dom_gnttab_init(dom)) != 0)
goto out;
-*console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
-*store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
+*console_mfn = xc_dom_p2m(dom, dom->console_pfn);
+*store_mfn = xc_dom_p2m(dom, dom->xenstore_pfn);
out:
return rc;
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 920fe42..0d80c18 100644
--- a/tools/libxc/
