[Xen-devel] live migration from new platform to old platform
Does anyone experience for HVM live migration from new generation platform to old generation platform? For X86 got a failure from Broadwell to Haswell, both platforms used same Xen version 4.7.0 RC3. [root@bdw-ep1 feng]# xl migrate 21 hsw-ep1 ... migration target: Ready to receive domain. Saving to migration stream new xl format (info 0x3/0x0/1537) Loading new save file (new xl fmt info 0x3/0x0/1537) Savefile contains xl domain config in JSON format Parsing config from xc: info: Saving domain 21, type x86 HVM xc: info: Found x86 HVM domain from Xen 4.7 xc: info: Restoring domain xc: error: Unable to restore HVM context (1 = Operation not permitted): Internal error xc: error: Restore failed (1 = Operation not permitted): Internal error libxl: error: libxl_stream_read.c:852:libxl__xc_domain_restore_done: restoring domain: Operation not permitted libxl: error: libxl_create.c:1220:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 31 libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy guest with domid 31 libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 31 failed migration target: Domain creation failed (code -3). libxl: error: libxl_utils.c:507:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration transport process [20867] exited with error status 1 Migration failed, resuming at sender. Guessing HVM context of some new instruction can't be restored to an old platform. Current Xen xl has cupid parameter parsing implement "cupid" in guest config, like cupid='host,xsave=0' or cpuid=[ '1:ecx=xxx0' ] So I tried to disable some new cupid in guest config, both of the two below method doesn't work, the HVM guest didn't disable those cupid such as "hle, rtm, rdseed...". cpuid='host,3dnowprefetch=0,hle=0,rtm=0,rdseed=0,adx=0,smap=0' cpuid=['7:ebx=xxx000xx0xx0'] From function libxl_cpuid_parse_config() of tools/libxl/libxl_cpuid.c, only some cupid are implemented. Feature lacking issue? Best Regards, Xudong ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 5/9] monitor: ARM SMC events
>>> On 06.06.16 at 18:38, wrote: > On 06/06/16 17:14, Tamas K Lengyel wrote: >> On Mon, Jun 6, 2016 at 9:56 AM, Tamas K Lengyel wrote: >>> On Mon, Jun 6, 2016 at 9:54 AM, Julien Grall wrote: >> So either way, I don't see a technical reason why Xen should silently >> swallow any SMC trap if the vm_event user specifically asked them to >> be forwarded. Other then it being odd that some ARM chips have varying >> behavior regarding a subset of SMC instructions, it should not affect >> when the vm_event user gets the events. If the user requests that it >> wants to get notified any time an SMC is trapped to the VMM, it >> should, regardless of whether that makes sense for "us". Depending on >> the use-case of the user, indeed it may need extra information if it >> wants to do emulation. If that need arises, the interface can easily >> be extended to accommodate that usecase. We can also add a comment >> saying that the forwarded events may also include ones with failed >> condition checks depending on the CPU implementation. Also, it would >> also be possible in the future to add a monitor configuration bit >> where the user can specify if it wants the failed condition check SMCs >> ignored by default or not. At this time however I want to start simple >> and just forward all events, adding more bits and pieces only as >> needed. > > We disagree on what is a "starting simple". It easier to relax than > restricting a behavior later one. > > Even if we decide to add a bit to ignore some SMC in a later version of > Xen, the introspection app will need to carry the burden mentioned in > lengthly way on the previous mails because they may want to support > older version of Xen. FWIW, I'm with Julien here given the information available so far on this thread. Some of the basic problem is that the original patch (and namely its modification to the public header) doesn't really make clear what's intended: To intercept all SMC instruction uses (aiui that's impossible on some hardware) or to intercept all privileged calls resulting from their use (in which case instances with the condition being false wouldn't count). What you, Tamas, want to get to seems to be some middle ground, which I don't see what use it would be to the consumer. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Discussion about virtual iommu support for Xen guest
>>> On 07.06.16 at 07:14, wrote: > After some internal discussion with Tianyu/Eddie, I realized my earlier > description is incomplete which takes only passthrough device into > consideration (as you saw it's mainly around interaction between vIOMMU > and pIOMMU). However from guest p.o.v, all the devices should be covered > by vIOMMU to match today's physical platform, including: > > 1) DMA-capable virtual device in Qemu, in Dom0 user space > 2) PV devices, in Dom0 kernel space > 3) Passthrough devices, in Xen hypervisor > > A natural implementation is to have vIOMMU together with where the > DMA is emulated, which ends up to a possible way with multiple vIOMMUs > in multiple layers: > > 1) vIOMMU in Dom0 user > 2) vIOMMU in Dom0 kernel > 3) vIOMMU in Xen hypervisor > > Of course we may come up an option to still keep all vIOMMUs in Xen > hypervisor, which however means every vDMA operations in Qemu or > BE driver need to issue Xen hypercall to get vIOMMU's approval. I haven't > thought thoroughly how big/complex this issue is, but it does be a > limitation from a quick thought. > > So, likely we'll have to consider presence of multiple vIOMMUs, each in > different layers, regardless of root-complex in Qemu or Xen. There > needs to be some interface abstractions to allow vIOMMU/root-complex > communicating with each other. Well, not an easy task... Right - for DMA-capable devices emulated in qemu, it would seem natural to have them go through a vIOMMU in qemu. Whether that vIOMMU implementation would have to consult the hypervisor (or perhaps even just be a wrapper around various hypercalls, i.e. backed by an implementation in the hypervisor) would be an independent aspect. Otoh, having vIOMMU in only qemu, and requiring round trips through qemu for any of the hypervisor's internal purposes doesn't seem like a good idea to me. And finally I don't see the relevance of PV devices here: Their nature makes it that they could easily be left completely independent of an vIOMMU (as long as there's no plan to bypass a virtualization level in the nested case, i.e. a PV frontend in L2 with a backend living in L0). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/serial: Fix incorrect length of strncmp for dtuart
>>> On 06.06.16 at 23:29, wrote: > In serial_parse_handler(), length of strncmp for dtuart should have been > 6, not 5. > > Signed-off-by: Jiandi An Reviewed-by: Jan Beulich Wei - trivial enough for inclusion in 4.7, I would think? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] live migration from new platform to old platform
>>> On 07.06.16 at 09:02, wrote: > Guessing HVM context of some new instruction can't be restored to an old > platform. Current Xen xl has cupid parameter parsing implement "cupid" in > guest config, like > cupid='host,xsave=0' > or > cpuid=[ '1:ecx=xxx0' ] > > So I tried to disable some new cupid in guest config, both of the two below > method doesn't work, the HVM guest didn't disable those cupid such as "hle, > rtm, rdseed...". > cpuid='host,3dnowprefetch=0,hle=0,rtm=0,rdseed=0,adx=0,smap=0' > cpuid=['7:ebx=xxx000xx0xx0'] This derivation of yours doesn't look right: Leaf 7 requires a sub-leaf to be specified (I don't recall off the top of my head what the exact syntax is). So I first of all wonder - did you verify that your CPUID adjustments actually too effect (in the sense of making it into d->arch.cpuids[])? Because once there, I can't see how the guest could get presented anything other than those values. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
>>> On 07.06.16 at 08:07, wrote: > On June 07, 2016 1:52 PM, Xu, Quan wrote: >> On June 02, 2016 8:09 PM, Jan Beulich wrote: >> > > Sorry, this below part is about NIC PF pass-through for win2008.. > >> btw, when I updated the NIC driver for win2008, actually, it is working. >> Xudong, could you help me verify it again? >> >> (( >> xen commit: bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b >> NIC: Intel Corporation I350 Gigabit Network Connection >> new win2k8 NIC >> driver ,https://downloadcenter.intel.com/download/18720/Network- >> Adapter-Driver-for-Windows-Server-2008-Final-Release?product=59679 >> )) >> >> qemu-dm-TestDom.log -- qemu log, pf PT for win2008. Okay, but could you please make explicit what works and what doesn't? I.e. do I take this to mean a passed through PF does work (at least with the newer driver, maybe also with an older one), while a passed through VF doesn't work (regardless of driver version)? Especially with you (earlier) suspecting a driver issue, precise information here is quite relevant. Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
>>> On 07.06.16 at 07:52, wrote: > -vf PT is not working for win2008: the logs: >qemu-dm-win2k8.log -- qemu log, vf PT for win2008. >xen-win2k8.log -- xen log, vf PT for win2008. Hmm, that's very little output. In particular neither qemu nor Xen see _any_ writes to the MSI-X table (without which interrupts obviously can't get enabled for that device). Albeit - even in the SLES case only qemu sees such writes, so I'll have to check if I made a mistake with the debugging patch. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch v6 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)
On June 02, 2016 5:21 PM, Jan Beulich wrote:
> >>> On 02.06.16 at 09:25, wrote:
> > On June 01, 2016 6:24 PM, Jan Beulich wrote:
> >> >>> On 31.05.16 at 15:57, wrote:
> > As would a respective change to vtd_set_hwdom_mapping(), which
> >> I'm not sure which patch you've put that in.
> >>
> >
> > Sorry, I missed it. I indeed it need to fix it as similar as above.
> > I wonder whether I could add a __must_check annotation to
> > iommu_map_page() or not, as which may be inconsistent with
> iommu_unmap_page().
>
> Urgh - are you saying that by the end of the series they aren't _both_
> __must_check? Then I must have overlooked something while reviewing: They
> definitely both ought to be. Or wait - I've pointed this out in the context
> of this
> patch, still seen below.
>
> >> > --- a/xen/include/xen/iommu.h
> >> > +++ b/xen/include/xen/iommu.h
> >> > @@ -166,8 +166,8 @@ struct iommu_ops { #endif /* HAS_PCI */
> >> >
> >> > void (*teardown)(struct domain *d);
> >> > -int (*map_page)(struct domain *d, unsigned long gfn, unsigned long
> mfn,
> >> > -unsigned int flags);
> >> > +int __must_check (*map_page)(struct domain *d, unsigned long gfn,
> >> > + unsigned long mfn, unsigned int
> >> > + flags);
> >>
> >> With this and with the rule set forth in the context of the
> >> discussion of
> > v5,
> >> iommu_map_page() (as well as any other caller of this hook that do
> >> not themselves _consume_ the error [e.g. hwdom init ones]) should
> >> become or already be __must_check, which afaict isn't the case.
> >
> > But does this rule also apply to these 'void' annotation functions?
> > .e.g, in the call tree of hwdom init ones / domain crash ones, we are
> > no need to bubble up error code, leaving these void annotation as is.
>
> Note that my previous reply already answered that question (as I expected
> you would otherwise ask): I specifically excluded those functions that
> _consume_ the error, and I did give an example. I really don't know what else
> I
> could have done to make clear what exceptions are to be expected.
>
> >> The same then, btw.,
> >> applies to patch 3, and hence I have to withdraw the R-b that you've
> >> got there.
> >
> > I find these callers are grant_table/mm, and we limit __must_check
> > annotation to IOMMU functions for this patch set..
>
> Talk isn't of those ones. The subject of patch 3 is unmapping, and hence the
> parallel to the one here is that iommu_unmap_page() needs to become
> __must_check there, along with the iommu_ops
> unmap_page() hook.
>
Jan,
I still have one question. If I add __must_check annotation to
iommu_unmap_page().
How to fix this -- unmapping the previous IOMMU maps when IOMMU mapping is
failed..
e.g.,
ept_set_entry()
{
...
for ( i = 0; i < (1 << order); i++ )
{
rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
iommu_flags);
if ( unlikely(rc) )
{
while ( i-- )
iommu_unmap_page(p2m->domain, gfn + i);
break;
}
}
...
}
If we leave it as is, it leads to compilation errors as __must_check
annotation. Also we return the first error, so we are no need to cumulate the
error of iommu_unmap_page().
That's also why I hesitated to add __must_check annotation to
iommu_unmap_page().
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/serial: Fix incorrect length of strncmp for dtuart
On Tue, Jun 07, 2016 at 01:29:34AM -0600, Jan Beulich wrote: > >>> On 06.06.16 at 23:29, wrote: > > In serial_parse_handler(), length of strncmp for dtuart should have been > > 6, not 5. > > > > Signed-off-by: Jiandi An > > Reviewed-by: Jan Beulich > > Wei - trivial enough for inclusion in 4.7, I would think? > Release-acked-by: Wei Liu > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
On June 07, 2016 3:50 PM, Jan Beulich wrote: > >>> On 07.06.16 at 07:52, wrote: > > -vf PT is not working for win2008: the logs: > >qemu-dm-win2k8.log -- qemu log, vf PT for win2008. > >xen-win2k8.log -- xen log, vf PT for win2008. > > Hmm, that's very little output. In particular neither qemu nor Xen see _any_ > writes to the MSI-X table (without which interrupts obviously can't get > enabled for that device). > > Albeit - even in the SLES case only qemu sees such writes, so I'll have to > check > if I made a mistake with the debugging patch. > I added more print-out when I debugged it.. I'll call Jianzhong, Chang for more information.. I __guess__ he makes vf work for win2008. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On Mon, Jun 06, 2016 at 03:40:33PM -0500, Doug Goldstein wrote: > On 6/6/16 10:59 AM, Wei Liu wrote: > > Wei Liu (6): > > xenconsoled: introduce log file abstraction > > xenconsoled: switch hypervisor log to use logfile abstraction > > xenconsoled: switch guest log to use logfile abstraction > > xenconsoled: delete two now unused functions > > xenconsoled: options to control log rotation > > xenconsoled: handle --log-backups 0 in logfile_rollover > > > > tools/console/daemon/io.c | 139 +++ > > tools/console/daemon/logfile.c | 243 > > + > > tools/console/daemon/logfile.h | 57 ++ > > tools/console/daemon/main.c| 13 ++- > > 4 files changed, 383 insertions(+), 69 deletions(-) > > create mode 100644 tools/console/daemon/logfile.c > > create mode 100644 tools/console/daemon/logfile.h > > > > Is there a mechanism for me to turn this off entirely? Due to some very > real possibilities like logging overwhelming xenconsoled and causing > qemu to block this is just not something that I will be able to roll out > in any of my deployments. We would rather lose logs than block qemu. > This is far from handling log for QEMU. That needs further discussion. Wei. > -- > Doug Goldstein > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
>>> On 07.06.16 at 09:49, wrote: On 07.06.16 at 07:52, wrote: >> -vf PT is not working for win2008: the logs: >>qemu-dm-win2k8.log -- qemu log, vf PT for win2008. >>xen-win2k8.log -- xen log, vf PT for win2008. > > Hmm, that's very little output. In particular neither qemu nor Xen > see _any_ writes to the MSI-X table (without which interrupts > obviously can't get enabled for that device). > > Albeit - even in the SLES case only qemu sees such writes, so I'll > have to check if I made a mistake with the debugging patch. With the exact same patches I do see MSI-X table writes logged with both SLES 11 and SLES 12 guests. What's going on here? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch v6 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)
>>> On 07.06.16 at 09:51, wrote:
> I still have one question. If I add __must_check annotation to
> iommu_unmap_page().
> How to fix this -- unmapping the previous IOMMU maps when IOMMU mapping is
> failed..
> e.g.,
>
> ept_set_entry()
> {
> ...
> for ( i = 0; i < (1 << order); i++ )
> {
> rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> iommu_flags);
> if ( unlikely(rc) )
> {
> while ( i-- )
> iommu_unmap_page(p2m->domain, gfn + i);
>
> break;
> }
> }
> ...
> }
>
>
> If we leave it as is, it leads to compilation errors as __must_check
> annotation. Also we return the first error, so we are no need to cumulate the
> error of iommu_unmap_page().
> That's also why I hesitated to add __must_check annotation to
> iommu_unmap_page().
Well, with there already being a message logged down the call
tree in case of error, I think the return value should simply be
latched into a local variable, and nothing really be done with it
(which should satisfy the compiler afaict, but it may be that
Coverity would grumble about such). We really don't want to omit
the __must_check just because there are a few cases where the
error is of no further relevance; the annotation gets put there to
make sure we catch all (current and future) cases where errors
must not be ignored.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
On June 07, 2016 4:09 PM, Jan Beulich wrote: > >>> On 07.06.16 at 09:49, wrote: > On 07.06.16 at 07:52, wrote: > >> -vf PT is not working for win2008: the logs: > >>qemu-dm-win2k8.log -- qemu log, vf PT for win2008. > >>xen-win2k8.log -- xen log, vf PT for win2008. > > > > Hmm, that's very little output. In particular neither qemu nor Xen see > > _any_ writes to the MSI-X table (without which interrupts obviously > > can't get enabled for that device). > > > > Albeit - even in the SLES case only qemu sees such writes, so I'll > > have to check if I made a mistake with the debugging patch. > > With the exact same patches I do see MSI-X table writes logged with both SLES > 11 and SLES 12 guests. What's going on here? > The internet cable is not plugged in for that NIC. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?
On Tue, Jun 07, 2016 at 12:38:26AM -0600, Jan Beulich wrote: > >>> On 06.06.16 at 19:18, wrote: > > The current issue I discover is that: > > > > xl vcpu-set jessie-hvm 4 > > xl list -l jessie-hvm | less # search for avail_vcpus > > > > A vcpu is not really considered online from xen's point of view, unless > > the guest explicitly activates it, like in guest `echo 1 > > > .../cpu1/online`. > > > > This is still not desirable because it would still cause qemu upstream > > migration to fail. I will see if there is other way to figure out how > > many vcpus are there. > > > > Off the top of my head I might need to interrogate QEMU for that. I will > > continue investigation later. > > > > Any hint on how to effectively identify online vcpus is very welcomed. > > How come xl itself doesn't know right from the "xl vcpu-set"? > That is because: 1. libxl only pulls data from various sources when it needs to right at the moment you ask for domain configuration. 2. For QEMU upstream, there is no way in telling whether a hotplug is successful or not -- the return value is ignored because response from QEMU is not sensible. Not saying these things are completely unfixable though. Wei. > And considering the guest reboot case I originally had the issue > with, the guest not activating the vCPU while still running would > not mean it won't use it post reboot. E.g. if the guest OS is not > CPU-hotplug capable, the reboot may be for the very reason of > activating the extra vCPU(s)... > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?
On Mon, Jun 06, 2016 at 06:34:44PM +0100, Andrew Cooper wrote: > On 06/06/16 18:20, Wei Liu wrote: > > Use Stefano's new email address > > > > On Mon, Jun 06, 2016 at 06:18:06PM +0100, Wei Liu wrote: > >> On Fri, Jun 03, 2016 at 05:35:20PM +0100, Wei Liu wrote: > >>> On Fri, Jun 03, 2016 at 08:42:11AM -0600, Jan Beulich wrote: > >>> On 03.06.16 at 15:41, wrote: > > On Fri, Jun 03, 2016 at 02:29:12AM -0600, Jan Beulich wrote: > >> Ian, Wei, > >> > >> is it intentional that rebooting a (HVM) guest after having altered its > >> vCPU count will reset it back to the vCPU count it was originally > >> started with? That doesn't seem very natural - if one hotplugs a CPU > >> into a physical system and then reboots, that CPU will remain there. > >> > > This is probably an oversight. > > > > I've added this to my list of things to look at after the release. > Thanks! > > >>> I got a patch ready. But QEMU upstream refuses to start on the receiving > >>> end > >>> with following error message: > >>> > >>> qemu-system-i386: Unknown savevm section or instance 'cpu_common' 1 > >>> qemu-system-i386: load of migration failed: Invalid argument > >>> > >>> With QEMU traditional HVM guest and PV guest, the guest works fine -- up > >>> and running with all hot plugged cpus available. > >>> > >>> So I think the relevant libxl information is transmitted but we also > >>> need to fix QEMU upstream. But that's a separate issue. > >>> > >>> Wei. > >>> > >>> ---8<--- > >>> From 790ff77c6307b341dec0b4cc5e2d394e42f82e7c Mon Sep 17 00:00:00 2001 > >>> From: Wei Liu > >>> Date: Fri, 3 Jun 2016 16:38:32 +0100 > >>> Subject: [PATCH] libxl: update vcpus bitmap in retrieved geust config > >>> > >>> ... because the available vcpu bitmap can change during domain life time > >>> due to cpu hotplug and unplug. > >>> > >>> Reported-by: Jan Beulich > >>> Signed-off-by: Wei Liu > >> This patch has two issues: > >> 1. The code to allocate bitmap is wrong > >> 2. The check to see if vcpu is available is wrong > >> > >> It happens to work on PV and qemu-trad because they don't really rely > >> on the bitmap provided. > >> > >> #1 is fixed. > >> > >> For #2, I haven't really gotten to the point today on how to correctly > >> get the number of online vcpus. > >> > >> The current issue I discover is that: > >> > >> xl vcpu-set jessie-hvm 4 > >> xl list -l jessie-hvm | less # search for avail_vcpus > >> > >> A vcpu is not really considered online from xen's point of view, unless > >> the guest explicitly activates it, like in guest `echo 1 > > >> .../cpu1/online`. > >> > >> This is still not desirable because it would still cause qemu upstream > >> migration to fail. I will see if there is other way to figure out how > >> many vcpus are there. > >> > >> Off the top of my head I might need to interrogate QEMU for that. I will > >> continue investigation later. > >> > >> Any hint on how to effectively identify online vcpus is very welcomed. > > Why does qemu even care? It has nothing to do with vcpu handling. > There should not be any qemu vcpu records in the first place. > IIRC upstream rejected the idea of having no cpu attached to a platform. Wei. > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PULL 3/4] xen: add pvUSB backend
On Mon, May 23, Gerd Hoffmann wrote: > +++ b/hw/usb/Makefile.objs > +common-obj-$(CONFIG_XEN_BACKEND) += xen-usb.o > +++ b/hw/usb/xen-usb.c > +usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops, > xen_sysdev); xen_sysdev is in an i386-only file, as a result qemu fails to link. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] live migration from new platform to old platform
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, June 7, 2016 3:39 PM > To: Hao, Xudong > Cc: Wei Liu ; Zhang, Haozhong > ; Xen-devel > Subject: Re: [Xen-devel] live migration from new platform to old platform > > >>> On 07.06.16 at 09:02, wrote: > > Guessing HVM context of some new instruction can't be restored to an > > old platform. Current Xen xl has cupid parameter parsing implement > > "cupid" in guest config, like cupid='host,xsave=0' > > or > > cpuid=[ '1:ecx=xxx0' ] > > > > So I tried to disable some new cupid in guest config, both of the two > > below method doesn't work, the HVM guest didn't disable those cupid > > such as "hle, rtm, rdseed...". > > cpuid='host,3dnowprefetch=0,hle=0,rtm=0,rdseed=0,adx=0,smap=0' > > cpuid=['7:ebx=xxx000xx0xx0'] > > This derivation of yours doesn't look right: Leaf 7 requires a sub-leaf to be > specified (I don't recall off the top of my head what the exact syntax is). > So I first > of all wonder - did you verify that your CPUID adjustments actually too > effect (in > the sense of making it into > d->arch.cpuids[])? Because once there, I can't see how the guest > could get presented anything other than those values. > Jan, Thanks. Yes, there is a Sub-leaf after leaf 7, with below additional line, migration succeed from Broadwell to Haswell. cpuid=['7,0:ebx=xxx000xx0xx0'] ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch v6 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)
On June 07, 2016 4:19 PM, Jan Beulich wrote:
> >>> On 07.06.16 at 09:51, wrote:
> > I still have one question. If I add __must_check annotation to
> > iommu_unmap_page().
> > How to fix this -- unmapping the previous IOMMU maps when IOMMU
> > mapping is failed..
> > e.g.,
> >
> > ept_set_entry()
> > {
> > ...
> > for ( i = 0; i < (1 << order); i++ )
> > {
> > rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> > iommu_flags);
> > if ( unlikely(rc) )
> > {
> > while ( i-- )
> > iommu_unmap_page(p2m->domain, gfn + i);
> >
> > break;
> > }
> > }
> > ...
> > }
> >
> >
> > If we leave it as is, it leads to compilation errors as __must_check
> > annotation. Also we return the first error, so we are no need to
> > cumulate the error of iommu_unmap_page().
> > That's also why I hesitated to add __must_check annotation to
> > iommu_unmap_page().
>
> Well, with there already being a message logged down the call tree in case of
> error, I think the return value should simply be latched into a local
> variable,
> and nothing really be done with it (which should satisfy the compiler afaict,
> but it may be that Coverity would grumble about such). We really don't want
> to omit the __must_check just because there are a few cases where the error
> is of no further relevance; the annotation gets put there to make sure we
> catch all (current and future) cases where errors must not be ignored.
>
Agreed. We really need to add __must_check annotation to iommu_map_page() /
iommu_unmap_page().
Along with discussion of a local variable for _for()_ loop, I need to define
this local variable into _while()_ loop:
e.g., as above case:
+while ( i-- )
+{
+int iommu_ret = iommu_unmap_page(p2m->domain, gfn + i);
+
+break;
+}
, right?
But I really like this way:
+ int iommu_ret;
+
+while ( i-- )
+{
+iommu_ret = iommu_unmap_page(p2m->domain, gfn + i);
+
+break;
+}
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v3 20/45] xen: dma-mapping: Use unsigned long for dma_attrs
On 02/06/16 16:39, Krzysztof Kozlowski wrote: > Split out subsystem specific changes for easier reviews. This will be > squashed with main commit. Acked-by: David Vrabel David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/serial: Fix incorrect length of strncmp for dtuart
In serial_parse_handler(), length of strncmp for dtuart should have been
6, not 5.
Signed-off-by: Jiandi An
---
xen/drivers/char/serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index c583a48..0fc5ced 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -310,7 +310,7 @@ int __init serial_parse_handle(char *conf)
goto common;
}
-if ( !strncmp(conf, "dtuart", 5) )
+if ( !strncmp(conf, "dtuart", 6) )
{
handle = SERHND_DTUART;
goto common;
--
Jiandi An
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Xenformat to analyze eventmask
Hello experts, I tried collecting trace of pv guest vm on xen 4.6.1 with xentrace. Command used for capturing trace: /usr/local/sbin/xentrace -D -e 0x0020f000 output.trace using xenformat to analyze trace command: cat output.trace | /usr/local/bin/xentrace_format myformats myformats contents: 0x0020f000 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) just want to print cpuid and timestamp for example but nothing shows up what i am doing wrong? Thanks Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
On Mon, 6 Jun 2016, Julien Grall wrote: > Hi Stefano, > > On 06/06/16 15:50, Stefano Stabellini wrote: > > On Mon, 6 Jun 2016, Shannon Zhao wrote: > > > I don't know why we need to disable ACPI because we can provide ACPI > > > tables but guest could choose to not use it. And for ARM32 domain, since > > > the linux guest kernel doesn't support ACPI, even we provide ACPI > > > tables, it can't use it, anyway. > > > > Memory usage. Simplicity: if you know you are not going to use ACPI, you > > might as well disable it to have one less moving piece (every line of > > code is potential for a bug). Guest configuration: if your guest > > operating system supports both ACPI and Device Tree and you want to be > > sure that Device Tree is the one that gets used, then you can do it by > > disabling ACPI at the VM level. Linux offers a command line option to do > > that, but other OSes might not and could choose ACPI by default. > > Other OSes would have the same problem on baremetal. A VM should reproduce the > baremetal behavior. If you have enabled both ACPI and DT in your kernel, then > you greed to let the kernel choose for you. > > However, I agree that an having option to enable/disable ACPI is useful. The > main use case would be embedded environment where ACPI will less used. That's right. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On 06/06/16 16:59, Wei Liu wrote: > Wei Liu (6): > xenconsoled: introduce log file abstraction > xenconsoled: switch hypervisor log to use logfile abstraction > xenconsoled: switch guest log to use logfile abstraction > xenconsoled: delete two now unused functions > xenconsoled: options to control log rotation > xenconsoled: handle --log-backups 0 in logfile_rollover What not use syslog and/or logrotate? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] live migration from new platform to old platform
On 07/06/16 08:02, Hao, Xudong wrote: > Does anyone experience for HVM live migration from new generation platform to > old generation platform? For X86 got a failure from Broadwell to Haswell, > both platforms used same Xen version 4.7.0 RC3. > > [root@bdw-ep1 feng]# xl migrate 21 hsw-ep1 > ... > migration target: Ready to receive domain. > Saving to migration stream new xl format (info 0x3/0x0/1537) Loading new save > file (new xl fmt info 0x3/0x0/1537) Savefile > contains xl domain config in JSON format Parsing config from > xc: info: Saving domain 21, type x86 HVM > xc: info: Found x86 HVM domain from Xen 4.7 > xc: info: Restoring domain > xc: error: Unable to restore HVM context (1 = Operation not permitted): > Internal error > xc: error: Restore failed (1 = Operation not permitted): Internal error > libxl: error: libxl_stream_read.c:852:libxl__xc_domain_restore_done: > restoring domain: Operation not permitted > libxl: error: libxl_create.c:1220:domcreate_rebuild_done: cannot (re-)build > domain: -3 > libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 31 > libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy guest > with domid 31 > libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 31 failed > migration target: Domain creation failed (code -3). > libxl: error: libxl_utils.c:507:libxl_read_exactly: file/stream truncated > reading ready message from migration receiver stream > libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration > transport process [20867] exited with error status 1 Migration failed, > resuming at sender. I see you have a solution to this problem. In general, `xl dmesg` on hsw-ep1 will provide some information as to why the restore failed. Given your hardware, I expect the problem was with CR4.SMAP. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
On Mon, 6 Jun 2016, Julien Grall wrote: > Hello, > > On 06/06/16 13:04, Stefano Stabellini wrote: > > On Mon, 6 Jun 2016, Julien Grall wrote: > > > On 06/06/16 12:40, Stefano Stabellini wrote: > > > > On Tue, 31 May 2016, Shannon Zhao wrote: > > > > > From: Shannon Zhao > > > > > > > > ACPI tables for ARM guests should be user configurable: acpi=1 in the VM > > > > config file enables them, with default off. > > > > > > The VM system specification for ARM [1] mandates that both ACPI and DT > > > should > > > be provided and described the entire VM and its peripheral (see the > > > section > > > "Hardware Description"). > > > > > > Furthermore, the user may not know if the guest OS will use ACPI or DT For > > > instance Redhat is using ACPI whilst Debian is using DT. > > > > > > So we have to provide both by default. However, 32-bit domain should only > > > have > > > Device-Tree table created. > > > > > > Anyway, the reason should have been described in the commit message. I > > > would > > > split this patch in two: introducing prepare ACPI and then GTDT table. So > > > we > > > can provide details in the commit message. > > > > All right, let me rephrase then: we should have a VMSPEC=on or off to > > enable or disable compliance with the VM system specification for ARM. > > (The good thing about specifications is that there are so many to choose > > from.) With compliance disabled, we can avoid introducing ACPI tables > > for the guest. > > > > Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and > > more meaningful alias: "ACPI" :-) > > The VM specification introduces other components such as a SBSA UART emulation > (which is not yet implemented by Xen). > > Do we want an option for each components? This is a good point. If one wants to avoid ACPI then she probably would want to avoid SBSA UART emulation too. So maybe after all it might be better to have a single vm_system_spec=1/0 option? I am OK with both having multiple options or just one. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 crash
Aaron Cornelius writes ("Re: [Xen-devel] Xen 4.7 crash"):
> We realized that we had forgotten to remove the domain from the
> permissions list when the domain is deleted (which would cause the error
> we saw). The application was updated to remove the domain from the
> permissions list:
> 1. retrieve the permissions with xs_get_permissions()
> 2. find the domain ID that is being deleted
> 3. memmove() the remaining domains down by 1 to "delete" the old domain
> from the permissions list
> 4. update the permissions with xs_set_permissions()
>
> After we made that change, a load test over the weekend confirmed that
> the Xen crash no longer happens. We checked this morning first thing
> and confirmed that without this change the crash reliably occurs.
This is rather odd behaviour. I don't think xenstored should hang
onto the domain's xs ring page just because the domain is still
mentioned in a permission list.
But it may do. I haven't checked the code. Are you using the
ocaml xenstored (oxenstored) or the C one ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: > On 06/06/16 16:59, Wei Liu wrote: > > Wei Liu (6): > > xenconsoled: introduce log file abstraction > > xenconsoled: switch hypervisor log to use logfile abstraction > > xenconsoled: switch guest log to use logfile abstraction > > xenconsoled: delete two now unused functions > > xenconsoled: options to control log rotation > > xenconsoled: handle --log-backups 0 in logfile_rollover > > What not use syslog and/or logrotate? > It's cumbersome to setup per guest facility for syslog. We don't want console log from different guests mix together in one file. Logrorate runs periodically. It doesn't actively limit the disk space consumed. The combination of syslog and logrotate can't prevent a guest from filling up Dom0 disk as far as I can tell. I'm happy to know if there is some sort of simple configuration we can ship with open source Xen. Wei. > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging
On 06/06/16 16:48, Wei Liu wrote:
>> A distro which isn't equipped to deal with these things is of no
>> practical use in the real world.
>>
>> Any distro we care about supporting is equipped to deal with logs.
>>
>>>
>>> I agree that if logging using existing logging systems were workable,
>>> that would be a better solution. Wei did actually spend a decent chunk
>>> of time looking at other options, including logrotate and journald
>>> before settling on using xenconsoled.
>>>
>>> A lot of this brainstorming and discussion happened off-list because
>>> XSA-180 was still embargoed, so I can understand why it looks like this
>>> came out of nowhere. It would probably be good for Wei to report here
>>> what he found and why he decided to propose this solution instead.
>>
>> Please do. Until there is an understanding of why the standard
>> mechanisms are not suitable, it is premature and naive to re-invent a wheel.
>>
>
> With syslog and logrotate you will still end up filling up your disk.
> Logrotate can't actively rotate log files.
FWIW CentOS 6 and 7 (which use rsyslogd and systemd-journald
respectively) seem to have rate-limiting stuff enabled by default; the
attached program causes a lot of CPU utilization, but no disk resource
exhaustion.
> You can't just tap syslog to QEMU at the moment unless you use the
> script I sent to XSA-180 security@ discussion. That's still a hacked up
> solution.
>
> I actually don't mind having syslog deal with those, but we need to
> provide some not-so-hacked-up way for doing it.
On Linux, it looks like you can create a socket and "connect" to /dev/log.
-George
#include
#include
int main(int argc, char * argv[]) {
int rc;
struct timespec tv = { .tv_nsec = 5000 };
openlog("DoS Attempt", 0, LOG_DAEMON);
while(!(rc = nanosleep(&tv, NULL))) {
syslog(LOG_ERR, "This is a nasty attempt to DoS syslog\n");
}
if(rc) {
perror("nanosleep");
}
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] xen/arm: build: add missed dependency for head.S
Julien Grall writes ("Re: [RFC] xen/arm: build: add missed dependency for
head.S"):
> On 03/06/16 11:07, Wei Chen wrote:
> > When we update the header files that had been included in head.S.
> > The build system would not re-compile the head.S. Because in the
> > build rules, the dependencies are setting to .*.d (eg. DEPS = .*.d)
> > files in the same folder as Makefile.
> >
> > But head.S is very special, it was used by the Makefile in the parent
> > folder: "ALL_OBJS := $(TARGET_SUBARCH)/head.o".
> >
> > In this case, the build system could not find the dependency in DEPS.
> > When we update the header files, the build system is unware of this
> > update. If we re-build the Xen without doing make clean or touching
> > the head.S, the build system will not recompile the head.S.
> >
> > Signed-off-by: Wei Chen
Acked-by: Ian Jackson
This should be in 4.7 and is a backport candidate.
> > In my mind, the better way to fix this bug is converting the DEPS from
> > ALL_OBJS. But I am afraid of the impact. I am not sure whether there
> > are some dependencies are not generated from obj files.
I do like this idea but I have the same worry. It might be possible
to dump ALL_OBJS out somehow and check this, but it might be
arch-dependent.
Wei Chen's patch is IMO a straightforward fix.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 95333: regressions - FAIL
flight 95333 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95333/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 11 guest-start/redhat.repeat fail REGR. vs. 95290 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 95290 test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-start/redhat.repeat fail REGR. vs. 95290 test-amd64-i386-qemuu-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 95290 test-amd64-amd64-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 95290 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 95290 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 95290 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 95290 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 95290 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 95290 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 95290 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 95290 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 95290 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 95290 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail REGR. vs. 95290 test-amd64-i386-xl-qemut-win7-amd64 9 windows-installfail REGR. vs. 95290 test-amd64-i386-xl-qemut-winxpsp3 9 windows-install fail REGR. vs. 95290 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 95290 test-amd64-amd64-xl-qemut-win7-amd64 9 windows-install fail REGR. vs. 95290 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 95290 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 95290 test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 95290 test-amd64-i386-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 95290 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 95290 test-amd64-amd64-qemuu-nested-amd 14 capture-logs/l1(14) fail blocked in 95290 test-armhf-armhf-xl-rtds 11 guest-start fail like 95250 test-amd64-amd64-xl-rtds 6 xen-boot fail like 95290 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-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never pass test-amd64-amd64-qemuu-nested-intel 14 capture-logs/l1(14) fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: xen d8ac67eff778ae0c6b3286ab46328be5c6c90163 baseline version: xen 8c4b40337b66679bbb776b157c747a946ed06de5 Last test of basis95290 2016-06-05 09:32:15 Z2 days Testing same since95333 2016-06-06 15:12:07 Z0 days1 attempts People who touched revisions under test: Ian Jackson jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt
Re: [Xen-devel] Discussion about virtual iommu support for Xen guest
On Tue, 7 Jun 2016, Tian, Kevin wrote: > > I think of QEMU as a provider of complex, high level emulators, such as > > the e1000, Cirrus VGA, SCSI controllers, etc., which don't necessarily > > need to be fast. > > Earlier you said Qemu imposes security issues. Here you said Qemu can > still provide complex emulators. Does it mean that security issue in Qemu > simply comes from the part which should be moved into Xen? Any > elaboration here? It imposes security issues because, although it doesn't have to run as root anymore, QEMU still has to run with fully privileged libxc and xenstore handles. In other words, a malicious guest breaking into QEMU would have relatively easy access to the whole host. There is a design to solve this, see Ian Jackson's talk at FOSDEM this year: https://fosdem.org/2016/schedule/event/virt_iaas_qemu_for_xen_secure_by_default/ https://fosdem.org/2016/schedule/event/virt_iaas_qemu_for_xen_secure_by_default/attachments/other/921/export/events/attachments/virt_iaas_qemu_for_xen_secure_by_default/other/921/talk.txt Other solutions to solve this issue are stubdoms or simply using PV guests and HVMlite guests only. Irrespective of the problematic security angle, which is unsolved, I think of QEMU as a provider of complex emulators, as I wrote above. Does it make sense? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] xen/arm: build: add missed dependency for head.S
Hi Ian,
On 07/06/16 11:03, Ian Jackson wrote:
Julien Grall writes ("Re: [RFC] xen/arm: build: add missed dependency for
head.S"):
On 03/06/16 11:07, Wei Chen wrote:
When we update the header files that had been included in head.S.
The build system would not re-compile the head.S. Because in the
build rules, the dependencies are setting to .*.d (eg. DEPS = .*.d)
files in the same folder as Makefile.
But head.S is very special, it was used by the Makefile in the parent
folder: "ALL_OBJS := $(TARGET_SUBARCH)/head.o".
In this case, the build system could not find the dependency in DEPS.
When we update the header files, the build system is unware of this
update. If we re-build the Xen without doing make clean or touching
the head.S, the build system will not recompile the head.S.
Signed-off-by: Wei Chen
Acked-by: Ian Jackson
This should be in 4.7 and is a backport candidate.
Sounds good to me.
In my mind, the better way to fix this bug is converting the DEPS from
ALL_OBJS. But I am afraid of the impact. I am not sure whether there
are some dependencies are not generated from obj files.
I do like this idea but I have the same worry. It might be possible
to dump ALL_OBJS out somehow and check this, but it might be
arch-dependent.
FWIW, Wei sent a new version today [1] which implement his suggestion.
Although it might be too risky for Xen 4.7.
Regards,
[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg00781.html
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 95350: trouble: blocked/broken
flight 95350 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95350/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken REGR. vs. 80927 build-i386-pvops 3 host-install(3) broken REGR. vs. 80927 build-i3863 host-install(3) broken REGR. vs. 80927 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pv 1 build-check(1) blocked n/a version targeted for testing: qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1 baseline version: qemuu10c1b763c26feb645627a1639e722515f3e1e876 Last test of basis80927 2016-02-06 13:30:02 Z 121 days Testing same since93977 2016-05-10 11:09:16 Z 27 days 116 attempts People who touched revisions under test: Gerd Hoffmann Stefano Stabellini jobs: build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-credit2 blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpublocked test-amd64-amd64-pairblo
Re: [Xen-devel] [Patch v6 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)
>>> On 07.06.16 at 10:40, wrote:
> Along with discussion of a local variable for _for()_ loop, I need to
> define this local variable into _while()_ loop:
> e.g., as above case:
>
> +while ( i-- )
> +{
> +int iommu_ret = iommu_unmap_page(p2m->domain, gfn + i);
> +
> +break;
> +}
>
> , right?
Something like this. As said, tricking Coverity into not reporting the
unused value as a possible problem would additionally be needed.
Andrew - do you know of any pre-existing pattern usable for this
purpose?
> But I really like this way:
>
> + int iommu_ret;
> +
> +while ( i-- )
> +{
> +iommu_ret = iommu_unmap_page(p2m->domain, gfn + i);
> +
> +break;
> +}
Rather not - iommu_ret isn't used outside of the while() scope.
(Unless, of course, the Coverity related adjustment makes this
desirable / necessary, but I would guess the tool would then still
be able to figure that the assignment is pointless on all but the
last iteration.)
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/serial: Fix incorrect length of strncmp for dtuart
On Mon, 6 Jun 2016, Jiandi An wrote:
> In serial_parse_handler(), length of strncmp for dtuart should have been
> 6, not 5.
>
> Signed-off-by: Jiandi An
Acked-by: Stefano Stabellini
> xen/drivers/char/serial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
> index c583a48..0fc5ced 100644
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -310,7 +310,7 @@ int __init serial_parse_handle(char *conf)
> goto common;
> }
>
> -if ( !strncmp(conf, "dtuart", 5) )
> +if ( !strncmp(conf, "dtuart", 6) )
> {
> handle = SERHND_DTUART;
> goto common;
> --
> Jiandi An
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On 07/06/16 10:55, Wei Liu wrote: > On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: >> On 06/06/16 16:59, Wei Liu wrote: >>> Wei Liu (6): >>> xenconsoled: introduce log file abstraction >>> xenconsoled: switch hypervisor log to use logfile abstraction >>> xenconsoled: switch guest log to use logfile abstraction >>> xenconsoled: delete two now unused functions >>> xenconsoled: options to control log rotation >>> xenconsoled: handle --log-backups 0 in logfile_rollover >> >> What not use syslog and/or logrotate? >> > > It's cumbersome to setup per guest facility for syslog. We don't want > console log from different guests mix together in one file. > > Logrorate runs periodically. It doesn't actively limit the disk space > consumed. > > The combination of syslog and logrotate can't prevent a guest from > filling up Dom0 disk as far as I can tell. I'm happy to know if there is > some sort of simple configuration we can ship with open source Xen. Ok. Found the other thread now. We should just use virtlogd instead of re-inventing the wheel. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] nested vmx: Intercept guest rdmsr for MSR_IA32_VMX_VMFUNC
Guest reads of MSR_IA32_VMX_VMFUNC should be handled by the logic in vmx_msr_read_intercept(). Otherwise a guest can read the raw host value of this MSR, even if nested vmx is disabled. Signed-off-by: Euan Harris --- xen/arch/x86/hvm/vmx/vmx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 743b5a1..6c0721f 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2624,7 +2624,7 @@ static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content) __vmread(GUEST_IA32_DEBUGCTL, msr_content); break; case IA32_FEATURE_CONTROL_MSR: -case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS: +case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC: if ( !nvmx_msr_read_intercept(msr, msr_content) ) goto gp_fault; break; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging
On Tue, Jun 07, 2016 at 10:57:14AM +0100, George Dunlap wrote:
> On 06/06/16 16:48, Wei Liu wrote:
> >> A distro which isn't equipped to deal with these things is of no
> >> practical use in the real world.
> >>
> >> Any distro we care about supporting is equipped to deal with logs.
> >>
> >>>
> >>> I agree that if logging using existing logging systems were workable,
> >>> that would be a better solution. Wei did actually spend a decent chunk
> >>> of time looking at other options, including logrotate and journald
> >>> before settling on using xenconsoled.
> >>>
> >>> A lot of this brainstorming and discussion happened off-list because
> >>> XSA-180 was still embargoed, so I can understand why it looks like this
> >>> came out of nowhere. It would probably be good for Wei to report here
> >>> what he found and why he decided to propose this solution instead.
> >>
> >> Please do. Until there is an understanding of why the standard
> >> mechanisms are not suitable, it is premature and naive to re-invent a
> >> wheel.
> >>
> >
> > With syslog and logrotate you will still end up filling up your disk.
> > Logrotate can't actively rotate log files.
>
> FWIW CentOS 6 and 7 (which use rsyslogd and systemd-journald
> respectively) seem to have rate-limiting stuff enabled by default; the
> attached program causes a lot of CPU utilization, but no disk resource
> exhaustion.
>
Not rate-limited on Debian Jessie installation. We can make
recommendation that system administrators should rate-limit syslog.
But CPU utilisation is also bad, just a different kind of "bad" from
disk exhaustion.
> > You can't just tap syslog to QEMU at the moment unless you use the
> > script I sent to XSA-180 security@ discussion. That's still a hacked up
> > solution.
> >
> > I actually don't mind having syslog deal with those, but we need to
> > provide some not-so-hacked-up way for doing it.
>
> On Linux, it looks like you can create a socket and "connect" to /dev/log.
>
That's the standard interface to syslog. I believe that's what openlog()
and syslog() use. We can open a socket and write to that, but you won't
get what you want without providing the correct formated message.
Try with:
sudo socat /dev/log STDIN
Wei.
> -George
>
> #include
> #include
>
> int main(int argc, char * argv[]) {
> int rc;
>
> struct timespec tv = { .tv_nsec = 5000 };
>
> openlog("DoS Attempt", 0, LOG_DAEMON);
>
> while(!(rc = nanosleep(&tv, NULL))) {
> syslog(LOG_ERR, "This is a nasty attempt to DoS syslog\n");
> }
>
> if(rc) {
> perror("nanosleep");
> }
> }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On Tue, Jun 07, 2016 at 11:17:07AM +0100, David Vrabel wrote: > On 07/06/16 10:55, Wei Liu wrote: > > On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: > >> On 06/06/16 16:59, Wei Liu wrote: > >>> Wei Liu (6): > >>> xenconsoled: introduce log file abstraction > >>> xenconsoled: switch hypervisor log to use logfile abstraction > >>> xenconsoled: switch guest log to use logfile abstraction > >>> xenconsoled: delete two now unused functions > >>> xenconsoled: options to control log rotation > >>> xenconsoled: handle --log-backups 0 in logfile_rollover > >> > >> What not use syslog and/or logrotate? > >> > > > > It's cumbersome to setup per guest facility for syslog. We don't want > > console log from different guests mix together in one file. > > > > Logrorate runs periodically. It doesn't actively limit the disk space > > consumed. > > > > The combination of syslog and logrotate can't prevent a guest from > > filling up Dom0 disk as far as I can tell. I'm happy to know if there is > > some sort of simple configuration we can ship with open source Xen. > > Ok. Found the other thread now. > > We should just use virtlogd instead of re-inventing the wheel. > As in importing that to our own tree (potentially a fork)? Provide interfaces to let system administrator configure that (need to at least check if it provides stable interfaces)? Not to mention to use that we need to add dependency to some sort of RPC library in our toolstack. Wei. > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xenformat to analyze eventmask
On Tue, 2016-06-07 at 12:48 +0530, andrew pheony wrote: > Hello experts, > > Â Â I tried collecting trace of pv guest vm on xen 4.6.1 with > xentrace. > Â Â Â Â Â Command used for capturing trace:Â /usr/local/sbin/xentrace > -D -e 0x0020f000 output.trace > What kind of events are you trying to capture and then analyze? Is it possible that what you want would be something like this: Â xentrace -D -e 0x2f000 output.trace (note the difference between your 0x20f000 and my 0x2f000) > Â Â Â Â using xenformat to analyze trace > Â Â Â Â command: Â Â Â Â Â > Â Â Â cat output.trace | /usr/local/bin/xentrace_format myformats > This part looks ok. Once you've got the event selection right, I'd suggest you to have a look at xenalyze as well. 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 0/6] xenconsoled: rotating log file abstration
On 07/06/16 11:21, Wei Liu wrote: > On Tue, Jun 07, 2016 at 11:17:07AM +0100, David Vrabel wrote: >> On 07/06/16 10:55, Wei Liu wrote: >>> On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: On 06/06/16 16:59, Wei Liu wrote: > Wei Liu (6): > xenconsoled: introduce log file abstraction > xenconsoled: switch hypervisor log to use logfile abstraction > xenconsoled: switch guest log to use logfile abstraction > xenconsoled: delete two now unused functions > xenconsoled: options to control log rotation > xenconsoled: handle --log-backups 0 in logfile_rollover What not use syslog and/or logrotate? >>> >>> It's cumbersome to setup per guest facility for syslog. We don't want >>> console log from different guests mix together in one file. >>> >>> Logrorate runs periodically. It doesn't actively limit the disk space >>> consumed. >>> >>> The combination of syslog and logrotate can't prevent a guest from >>> filling up Dom0 disk as far as I can tell. I'm happy to know if there is >>> some sort of simple configuration we can ship with open source Xen. >> >> Ok. Found the other thread now. >> >> We should just use virtlogd instead of re-inventing the wheel. >> > > As in importing that to our own tree (potentially a fork)? Provide > interfaces to let system administrator configure that (need to at least > check if it provides stable interfaces)? Of course not! It would simply be an external dependency. > Not to mention to use that we need to add dependency to some sort of RPC > library in our toolstack. So? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 5/9] monitor: ARM SMC events
On Tue, 7 Jun 2016, Jan Beulich wrote: > >>> On 06.06.16 at 18:38, wrote: > > On 06/06/16 17:14, Tamas K Lengyel wrote: > >> On Mon, Jun 6, 2016 at 9:56 AM, Tamas K Lengyel > >> wrote: > >>> On Mon, Jun 6, 2016 at 9:54 AM, Julien Grall wrote: > >> So either way, I don't see a technical reason why Xen should silently > >> swallow any SMC trap if the vm_event user specifically asked them to > >> be forwarded. Other then it being odd that some ARM chips have varying > >> behavior regarding a subset of SMC instructions, it should not affect > >> when the vm_event user gets the events. If the user requests that it > >> wants to get notified any time an SMC is trapped to the VMM, it > >> should, regardless of whether that makes sense for "us". Depending on > >> the use-case of the user, indeed it may need extra information if it > >> wants to do emulation. If that need arises, the interface can easily > >> be extended to accommodate that usecase. We can also add a comment > >> saying that the forwarded events may also include ones with failed > >> condition checks depending on the CPU implementation. Also, it would > >> also be possible in the future to add a monitor configuration bit > >> where the user can specify if it wants the failed condition check SMCs > >> ignored by default or not. At this time however I want to start simple > >> and just forward all events, adding more bits and pieces only as > >> needed. > > > > We disagree on what is a "starting simple". It easier to relax than > > restricting a behavior later one. > > > > Even if we decide to add a bit to ignore some SMC in a later version of > > Xen, the introspection app will need to carry the burden mentioned in > > lengthly way on the previous mails because they may want to support > > older version of Xen. > > FWIW, I'm with Julien here given the information available so far > on this thread. Some of the basic problem is that the original > patch (and namely its modification to the public header) doesn't > really make clear what's intended: To intercept all SMC instruction > uses (aiui that's impossible on some hardware) or to intercept all > privileged calls resulting from their use (in which case instances > with the condition being false wouldn't count). Right. I think that the first thing to do would be to write down in the public header file what is the intended behavior. Given the scope for confusion, this is necessary regardless of the chosen behavior. > What you, Tamas, want to get to seems to be some middle > ground, which I don't see what use it would be to the consumer. I think that forwarding SMC events only for unconditional SMCs and SMCs which succeeded the conditional check would make for a better interface. This would be my preference. If you really want to forward SMC events for SMCs which failed the conditional check, then please add to the SMC event struct all the necessary information so that the monitoring application can quickly find out whether the conditional check succeeded or failed without jumping through hoops. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On Tue, Jun 07, 2016 at 11:29:31AM +0100, David Vrabel wrote: > On 07/06/16 11:21, Wei Liu wrote: > > On Tue, Jun 07, 2016 at 11:17:07AM +0100, David Vrabel wrote: > >> On 07/06/16 10:55, Wei Liu wrote: > >>> On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: > On 06/06/16 16:59, Wei Liu wrote: > > Wei Liu (6): > > xenconsoled: introduce log file abstraction > > xenconsoled: switch hypervisor log to use logfile abstraction > > xenconsoled: switch guest log to use logfile abstraction > > xenconsoled: delete two now unused functions > > xenconsoled: options to control log rotation > > xenconsoled: handle --log-backups 0 in logfile_rollover > > What not use syslog and/or logrotate? > > >>> > >>> It's cumbersome to setup per guest facility for syslog. We don't want > >>> console log from different guests mix together in one file. > >>> > >>> Logrorate runs periodically. It doesn't actively limit the disk space > >>> consumed. > >>> > >>> The combination of syslog and logrotate can't prevent a guest from > >>> filling up Dom0 disk as far as I can tell. I'm happy to know if there is > >>> some sort of simple configuration we can ship with open source Xen. > >> > >> Ok. Found the other thread now. > >> > >> We should just use virtlogd instead of re-inventing the wheel. > >> > > > > As in importing that to our own tree (potentially a fork)? Provide > > interfaces to let system administrator configure that (need to at least > > check if it provides stable interfaces)? > > Of course not! It would simply be an external dependency. > > > Not to mention to use that we need to add dependency to some sort of RPC > > library in our toolstack. > > So? > That's something I would like to avoid if possible. This is just for guest console logging. It's definitely not a good idea to add that to xenconsoled. Please don't mix this thread with the other on-going discussion about QEMU logging. Wei. > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] nested vmx: Intercept guest rdmsr for MSR_IA32_VMX_VMFUNC
>>> On 07.06.16 at 12:18, wrote: > Guest reads of MSR_IA32_VMX_VMFUNC should be handled by > the logic in vmx_msr_read_intercept(). Otherwise a guest > can read the raw host value of this MSR, even if nested > vmx is disabled. > > Signed-off-by: Euan Harris Reviewed-by: Jan Beulich Albeit ... > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -2624,7 +2624,7 @@ static int vmx_msr_read_intercept(unsigned int msr, > uint64_t *msr_content) > __vmread(GUEST_IA32_DEBUGCTL, msr_content); > break; > case IA32_FEATURE_CONTROL_MSR: > -case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS: > +case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC: > if ( !nvmx_msr_read_intercept(msr, msr_content) ) > goto gp_fault; > break; ... retaining this code structure makes it likely that some future addition will lead to the same problem again. I think there should be something like MSR_IA32_VMX_LAST added to msr-index.h, and get used here instead. Suitably placed it would make pretty obvious to someone adding a new MSR there that this value also needs updating. Or alternatively: Is there an architectural upper bound to the VMX MSR range? If so, we could widen the set to the full range in one go. VMX maintainers - I'd appreciate if you could take care of this in one way or another. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk wrote: > --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100 > +++ xen-4.7.0/config/StdGNU.mk 2016-04-15 23:01:40.978829756 +0100 > @@ -37,6 +37,12 @@ > > ifneq ($(debug),y) > CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars > +ifeq ($(XEN_TARGET_ARCH),x86_64) > +#might be cross-compiling so strip out possible x86_32 options > +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e > 's/-march=i686//g' -e 's/-mtune=atom//g') > +else > +CFLAGS += $(CFLAGS_EXTRA) > +endif Why the if? Under what circumstances is it actually appropriate to pass in those kinds of flags to the Xen build system? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On 07/06/16 11:34, Wei Liu wrote: > On Tue, Jun 07, 2016 at 11:29:31AM +0100, David Vrabel wrote: >> On 07/06/16 11:21, Wei Liu wrote: >>> On Tue, Jun 07, 2016 at 11:17:07AM +0100, David Vrabel wrote: On 07/06/16 10:55, Wei Liu wrote: > On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: >> On 06/06/16 16:59, Wei Liu wrote: >>> Wei Liu (6): >>> xenconsoled: introduce log file abstraction >>> xenconsoled: switch hypervisor log to use logfile abstraction >>> xenconsoled: switch guest log to use logfile abstraction >>> xenconsoled: delete two now unused functions >>> xenconsoled: options to control log rotation >>> xenconsoled: handle --log-backups 0 in logfile_rollover >> >> What not use syslog and/or logrotate? >> > > It's cumbersome to setup per guest facility for syslog. We don't want > console log from different guests mix together in one file. > > Logrorate runs periodically. It doesn't actively limit the disk space > consumed. > > The combination of syslog and logrotate can't prevent a guest from > filling up Dom0 disk as far as I can tell. I'm happy to know if there is > some sort of simple configuration we can ship with open source Xen. Ok. Found the other thread now. We should just use virtlogd instead of re-inventing the wheel. >>> >>> As in importing that to our own tree (potentially a fork)? Provide >>> interfaces to let system administrator configure that (need to at least >>> check if it provides stable interfaces)? >> >> Of course not! It would simply be an external dependency. >> >>> Not to mention to use that we need to add dependency to some sort of RPC >>> library in our toolstack. >> >> So? >> > > That's something I would like to avoid if possible. This is just for > guest console logging. It's definitely not a good idea to add that to > xenconsoled. Why is it a bad idea to make use of an existing solution? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] xenconsoled: rotating log file abstration
On Tue, Jun 07, 2016 at 11:35:41AM +0100, David Vrabel wrote: > On 07/06/16 11:34, Wei Liu wrote: > > On Tue, Jun 07, 2016 at 11:29:31AM +0100, David Vrabel wrote: > >> On 07/06/16 11:21, Wei Liu wrote: > >>> On Tue, Jun 07, 2016 at 11:17:07AM +0100, David Vrabel wrote: > On 07/06/16 10:55, Wei Liu wrote: > > On Tue, Jun 07, 2016 at 10:44:50AM +0100, David Vrabel wrote: > >> On 06/06/16 16:59, Wei Liu wrote: > >>> Wei Liu (6): > >>> xenconsoled: introduce log file abstraction > >>> xenconsoled: switch hypervisor log to use logfile abstraction > >>> xenconsoled: switch guest log to use logfile abstraction > >>> xenconsoled: delete two now unused functions > >>> xenconsoled: options to control log rotation > >>> xenconsoled: handle --log-backups 0 in logfile_rollover > >> > >> What not use syslog and/or logrotate? > >> > > > > It's cumbersome to setup per guest facility for syslog. We don't want > > console log from different guests mix together in one file. > > > > Logrorate runs periodically. It doesn't actively limit the disk space > > consumed. > > > > The combination of syslog and logrotate can't prevent a guest from > > filling up Dom0 disk as far as I can tell. I'm happy to know if there is > > some sort of simple configuration we can ship with open source Xen. > > Ok. Found the other thread now. > > We should just use virtlogd instead of re-inventing the wheel. > > >>> > >>> As in importing that to our own tree (potentially a fork)? Provide > >>> interfaces to let system administrator configure that (need to at least > >>> check if it provides stable interfaces)? > >> > >> Of course not! It would simply be an external dependency. > >> > >>> Not to mention to use that we need to add dependency to some sort of RPC > >>> library in our toolstack. > >> > >> So? > >> > > > > That's something I would like to avoid if possible. This is just for > > guest console logging. It's definitely not a good idea to add that to > > xenconsoled. > > Why is it a bad idea to make use of an existing solution? > The burden of maintaining the interface to an external dependency is larger then writing our own code in this particular instance. Wei. > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
On Tue, 7 Jun 2016, George Dunlap wrote: > On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk > wrote: > > --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100 > > +++ xen-4.7.0/config/StdGNU.mk 2016-04-15 23:01:40.978829756 +0100 > > @@ -37,6 +37,12 @@ > > > > ifneq ($(debug),y) > > CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars > > +ifeq ($(XEN_TARGET_ARCH),x86_64) > > +#might be cross-compiling so strip out possible x86_32 options > > +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e > > 's/-march=i686//g' -e 's/-mtune=atom//g') > > +else > > +CFLAGS += $(CFLAGS_EXTRA) > > +endif > > Why the if? Under what circumstances is it actually appropriate to > pass in those kinds of flags to the Xen build system? That may not be needed in general. It is something I added for Fedora as I am cross-compiling the hypervisor as x86_64 to put in the i686 package because ix86 hypervisors are no longer supported. Michael Young ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
>>> On 07.06.16 at 12:35, wrote: > On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk > wrote: >> --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100 >> +++ xen-4.7.0/config/StdGNU.mk 2016-04-15 23:01:40.978829756 +0100 >> @@ -37,6 +37,12 @@ >> >> ifneq ($(debug),y) >> CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars >> +ifeq ($(XEN_TARGET_ARCH),x86_64) >> +#might be cross-compiling so strip out possible x86_32 options >> +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e >> 's/-march=i686//g' -e 's/-mtune=atom//g') >> +else >> +CFLAGS += $(CFLAGS_EXTRA) >> +endif > > Why the if? Under what circumstances is it actually appropriate to > pass in those kinds of flags to the Xen build system? -m options in general are machine specific, so any of those three may have a meaning on e.g. ARM (I agree that at least for the latter two this is rather unlikely, but anyway). Otoh I can't really see the purpose of this stripping: If we're cross compiling, the extra flags should be set accordingly by the invoking environment. What I find odd is that this gets put inside a debug=n only section. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
On Tue, Jun 7, 2016 at 11:42 AM, M A Young wrote: > On Tue, 7 Jun 2016, George Dunlap wrote: > >> On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk >> wrote: >> > --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100 >> > +++ xen-4.7.0/config/StdGNU.mk 2016-04-15 23:01:40.978829756 +0100 >> > @@ -37,6 +37,12 @@ >> > >> > ifneq ($(debug),y) >> > CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars >> > +ifeq ($(XEN_TARGET_ARCH),x86_64) >> > +#might be cross-compiling so strip out possible x86_32 options >> > +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e >> > 's/-march=i686//g' -e 's/-mtune=atom//g') >> > +else >> > +CFLAGS += $(CFLAGS_EXTRA) >> > +endif >> >> Why the if? Under what circumstances is it actually appropriate to >> pass in those kinds of flags to the Xen build system? > > That may not be needed in general. It is something I added for Fedora as I > am cross-compiling the hypervisor as x86_64 to put in the i686 package > because ix86 hypervisors are no longer supported. It could be argued that the person setting CFLAGS_EXTRA should remove those before calling 'make xen' when cross-compiling. Setting CFLAGS_EXTRA=-m32 make XEN_TARGET_ARCH=x86_64 doesn't really make much sense. :-) At the moment, for example, I've got to unset all additional CFLAGS before calling "make stubdom" or the resulting pvgrub images crash on boot. To be consistent we should try to either 1) Make it the caller's job to make sure not to pass in inappropriate arguments, or 2) make it Xen's job to filter out all inappropriate options. I'm inclined to go with #1, at least to begin with, for simplicity. What do you think? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
On Tue, 7 Jun 2016, Jan Beulich wrote: > >>> On 07.06.16 at 12:35, wrote: > > On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk > > wrote: > >> --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100 > >> +++ xen-4.7.0/config/StdGNU.mk 2016-04-15 23:01:40.978829756 +0100 > >> @@ -37,6 +37,12 @@ > >> > >> ifneq ($(debug),y) > >> CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars > >> +ifeq ($(XEN_TARGET_ARCH),x86_64) > >> +#might be cross-compiling so strip out possible x86_32 options > >> +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e > >> 's/-march=i686//g' -e 's/-mtune=atom//g') > >> +else > >> +CFLAGS += $(CFLAGS_EXTRA) > >> +endif > > > > Why the if? Under what circumstances is it actually appropriate to > > pass in those kinds of flags to the Xen build system? > > -m options in general are machine specific, so any of those three > may have a meaning on e.g. ARM (I agree that at least for the > latter two this is rather unlikely, but anyway). Otoh I can't really > see the purpose of this stripping: If we're cross compiling, the > extra flags should be set accordingly by the invoking environment. > > What I find odd is that this gets put inside a debug=n only section. I happened to put it there because I was editing the same section to trace a gcc bug (note the addition of -fno-tree-coalesce-vars in the line above for that patch). It can go elsewhere, though note that the CFLAGS from the OS may contain the -O2 option which might interfere with the debug options. Michael Young ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] nested vmx: Intercept guest rdmsr for MSR_IA32_VMX_VMFUNC
On Tue, Jun 07, 2016 at 04:35:28AM -0600, Jan Beulich wrote: > > @@ -2624,7 +2624,7 @@ static int vmx_msr_read_intercept(unsigned int msr, > > uint64_t *msr_content) > > __vmread(GUEST_IA32_DEBUGCTL, msr_content); > > break; > > case IA32_FEATURE_CONTROL_MSR: > > -case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS: > > +case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC: > > if ( !nvmx_msr_read_intercept(msr, msr_content) ) > > goto gp_fault; > > break; > > ... retaining this code structure makes it likely that some future > addition will lead to the same problem again. The safest solution would be to whitelist the MSRs which Xen handles and which the guest should be allowed to see, rather than blacklisting which is essentially what is happening now. That would involve a substantial change in the code, but aside from that is there any fundamental reason why it would be a bad idea? Thanks, Euan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 00/14] Xen ARM DomU ACPI support
Hello Boris, On 06/06/16 17:50, Boris Ostrovsky wrote: On 06/06/2016 11:37 AM, Boris Ostrovsky wrote: What I don't want to see is that x86 builds its ACPI table in libxc while ARM builds its in libxl. That would make future merger harder. Boris? TBH, I am not sure which library this should really belong to. I felt libxc would be more appropriate. Actually, I now remember why I picked libxc: because I wanted ACPI pages to be loaded as part of xc_dom_build_image(). What about adding a new field in xc_dom_image? For the device tree, libxl is provide a buffer which will be loaded as part of xc_dom_build_image (see devicetree_blob). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 00/14] Xen ARM DomU ACPI support
Hello Shannon, On 07/06/16 02:07, Shannon Zhao wrote: On 2016/6/6 23:48, Julien Grall wrote: On 06/06/16 13:26, Wei Liu wrote: On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote: From: Shannon Zhao The design of this feature is described as below. Firstly, the toolstack (libxl) generates the ACPI tables according the number of vcpus and gic controller. Then, it copies these ACPI tables to DomU memory space and passes them to UEFI firmware through the "ARM multiboot" protocol. At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol and installs these tables like the usual way and passes both ACPI and DT information to the Xen DomU. Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables since it's enough now. This has been tested using guest kernel with the Dom0 ACPI support patches which could be fetched from: https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen Shannon Zhao (14): libxl/arm: Fix the function name in error log libxl/arm: Factor out codes for generating DTB libxc: Add placeholders for ACPI tables blob and size tools: add ACPI tables relevant definitions libxl/arm: Construct ACPI GTDT table libxl/arm: Construct ACPI FADT table libxl/arm: Construct ACPI DSDT table libxl/arm: Construct ACPI MADT table libxl/arm: Construct ACPI XSDT table libxl/arm: Construct ACPI RSDP table libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ libxl/arm: Add ACPI module libxl/arm: initialize memory information of ACPI blob libxc/xc_dom_core: Copy ACPI tables to guest memory space After going through this series, I think the code mostly looks good. There is one higher level question: you seem to have put a lot of the table construction code in libxl, while I failed to see why specific libxl information is needed. Have you considered moving the code to libxc? I would rather avoid to have the device tree built by libxl and ACPI tables built by libxc. I don't remember why we have decided to implement DT building in libxl, I guess it is because we need to know which GIC version is used (GICv2 vs GICv3). In the long run, we might also need to have more part of the firmware configurable (performance monitor support, memory layout, UART...). Most of those information are available easily in libxl, we would to export them of libxc. Yes, and one more reason is that to support ACPI, it also needs to add the ACPI multiboot module in DT. I don't consider this as a reason for building the ACPI tables in libxl. I am more concerned about building the firmwares in different place. If we decide to build the ACPI tables in libxc, then the code to build the device tree should move in libxc too. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
Hello, On 06/06/16 13:18, Wei Liu wrote: On Tue, May 31, 2016 at 01:02:57PM +0800, Shannon Zhao wrote: +static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info, +libxl__domain_build_state *state, +struct xc_dom_image *dom) libxl__prepare_acpi I would also suggest moving ACPI related functions to a dedicated file (libxl_arm_acpi.c) so that the possible future merger with x86 code can be made easier. +1 and it makes sense to have the code to build the Device Tree and the ACPI tables in a separate files. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
Is there any particular reason to expose the list of the tables outside
of the building code?
I would provide a single buffer with all the tables inside. Similar to
what you did for building the tables in the hypervisor.
+
struct xc_dom_image {
/* files */
void *kernel_blob;
@@ -64,6 +78,8 @@ struct xc_dom_image {
size_t ramdisk_size;
void *devicetree_blob;
size_t devicetree_size;
+struct acpitable_blob *acpitable_blob;
+size_t acpitable_size;
size_t max_kernel_size;
size_t max_ramdisk_size;
@@ -92,6 +108,7 @@ struct xc_dom_image {
struct xc_dom_seg p2m_seg;
struct xc_dom_seg pgtables_seg;
struct xc_dom_seg devicetree_seg;
+struct xc_dom_seg acpi_seg;
struct xc_dom_seg start_info_seg; /* HVMlite only */
xen_pfn_t start_info_pfn;
xen_pfn_t console_pfn;
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 2016/6/7 19:05, Julien Grall wrote:
> Hello Shannon,
>
> On 31/05/16 06:02, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
>> for ARM VM. So only add placeholders for them here.
>>
>> Signed-off-by: Shannon Zhao
>> ---
>> tools/libxc/include/xc_dom.h | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
>> index 6cb10c4..0fe54dd 100644
>> --- a/tools/libxc/include/xc_dom.h
>> +++ b/tools/libxc/include/xc_dom.h
>> @@ -56,6 +56,20 @@ struct xc_dom_phys {
>> xen_pfn_t count;
>> };
>>
>> +struct acpitable {
>> +void *table;
>> +size_t size;
>> +};
>> +
>> +struct acpitable_blob {
>> +struct acpitable rsdp;
>> +struct acpitable xsdt;
>> +struct acpitable gtdt;
>> +struct acpitable madt;
>> +struct acpitable fadt;
>> +struct acpitable dsdt;
>> +};
>
> Is there any particular reason to expose the list of the tables outside
> of the building code?
>
> I would provide a single buffer with all the tables inside. Similar to
> what you did for building the tables in the hypervisor.
When it loads these tables to guest memory space, it needs to update the
entries (pointing to other tables) of XSDT and also the
xsdt_physical_address in RSDP.
So it needs to know the length of each table and copy them separately.
Please see patch 14.
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 9e99159..0fb4f69 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -3,6 +3,7 @@
#include "libxl_libfdt_compat.h"
#include
+#include
#include
#include
#include
@@ -880,13 +881,85 @@ out:
return rc;
}
+static void make_acpi_header(struct acpi_table_header *h, const char *sig,
+ int len, uint8_t rev)
+{
+memcpy(&h->signature, sig, 4);
+h->length = len;
+h->revision = rev;
+memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
+memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
+memcpy(h->oem_table_id + 4, sig, 4);
+h->oem_revision = 1;
+memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
+h->asl_compiler_revision = 1;
+h->checksum = 0;
Should not we compute the checksum here?
+}
+
+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_gtdt_descriptor *gtdt;
+
+gtdt = libxl__zalloc(gc, sizeof(*gtdt));
+
+gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
+gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
There is no secure EL1 for guest, so this should be 0.
+gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
+gtdt->non_secure_el1_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
+gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
+gtdt->virtual_timer_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
+
+make_acpi_header(>dt->header, "GTDT", sizeof(*gtdt), 2);
+
+dom->acpitable_blob->gtdt.table = (void *)gtdt;
+/* Align to 64bit. */
I am not sure what the comment is for.
+dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
+dom->acpitable_size += dom->acpitable_blob->gtdt.size;
+}
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/3] libxl: update available vcpus map in retrieve configuration function
Wei Liu (3): libxl: introduce libxl__json_array_count libxl: introduce libxl__qmp_query_cpus libxl: update vcpus bitmap in retrieved guest config tools/libxl/libxl.c | 91 tools/libxl/libxl_internal.h | 4 ++ tools/libxl/libxl_json.c | 11 ++ tools/libxl/libxl_qmp.c | 19 + 4 files changed, 125 insertions(+) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/3] libxl: introduce libxl__json_array_count
It returns the number of elements in a json array.
It will be used later.
Signed-off-by: Wei Liu
---
tools/libxl/libxl_internal.h | 1 +
tools/libxl/libxl_json.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ae16c25..38ec54d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1979,6 +1979,7 @@ _hidden int libxl__json_object_append_to(libxl__gc
*gc_opt,
libxl__yajl_ctx *ctx);
_hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
int i);
+_hidden unsigned int libxl__json_array_count(const libxl__json_object *o);
_hidden
libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
int i);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index b60ae2b..3b744fb 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -546,6 +546,17 @@ void libxl__json_object_free(libxl__gc *gc,
libxl__json_object *obj)
free(obj);
}
+unsigned int libxl__json_array_count(const libxl__json_object *o)
+{
+flexarray_t *array = NULL;
+
+assert(libxl__json_object_is_array(o));
+array = libxl__json_object_get_array(o);
+assert(array);
+
+return array->count;
+}
+
libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i)
{
flexarray_t *array = NULL;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/3] libxl: introduce libxl__qmp_query_cpus
It interrogates QEMU for the number of cpus.
Signed-off-by: Wei Liu
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_qmp.c | 19 +++
2 files changed, 22 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 38ec54d..5c22b97 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1794,6 +1794,9 @@ _hidden int libxl__qmp_set_global_dirty_log(libxl__gc
*gc, int domid, bool enabl
_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const
libxl_device_disk *disk);
/* Add a virtual CPU */
_hidden int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int index);
+/* Query the number of CPUs */
+_hidden int libxl__qmp_query_cpus(libxl__gc *gc, int domid,
+ unsigned int *count);
/* Start NBD server */
_hidden int libxl__qmp_nbd_server_start(libxl__gc *gc, int domid,
const char *host, const char *port);
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 3eb279a..b9de867 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -979,6 +979,25 @@ int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int idx)
return qmp_run_command(gc, domid, "cpu-add", args, NULL, NULL);
}
+static int query_cpus_callback(libxl__qmp_handler *qmp,
+ const libxl__json_object *response,
+ void *opaque)
+{
+unsigned int *count = opaque;
+GC_INIT(qmp->ctx);
+
+*count = libxl__json_array_count(response);
+
+GC_FREE;
+return 0;
+}
+
+int libxl__qmp_query_cpus(libxl__gc *gc, int domid, unsigned int *count)
+{
+return qmp_run_command(gc, domid, "query-cpus", NULL,
+ query_cpus_callback, count);
+}
+
int libxl__qmp_nbd_server_start(libxl__gc *gc, int domid,
const char *host, const char *port)
{
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/3] libxl: update vcpus bitmap in retrieved guest config
... because the available vcpu bitmap can change during domain life time
due to cpu hotplug and unplug.
For QEMU upstream, we interrogate QEMU for the number of vcpus. For
others, we look directly into xenstore for information.
Reported-by: Jan Beulich
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c | 91 +
1 file changed, 91 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 006b83f..4f8b663 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -7222,6 +7222,57 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
libxl_mac *src)
(*dst)[i] = (*src)[i];
}
+static int libxl__update_avail_vcpus_qmp(libxl__gc *gc, uint32_t domid,
+ unsigned int max_vcpus,
+ libxl_bitmap *map)
+{
+unsigned int count, i;
+int rc;
+
+/* For QEMU upstream we always need to return the number
+ * of cpus present to QEMU whether they are online or not;
+ * otherwise QEMU won't accept the saved state.
+ */
+rc = libxl__qmp_query_cpus(gc, domid, &count);
+if (rc) {
+LOG(ERROR, "fail to get number of cpus for domain %d", domid);
+goto out;
+}
+
+for (i = 0; i < count; i++)
+libxl_bitmap_set(map, i);
+
+rc = 0;
+out:
+return rc;
+}
+
+static int libxl__update_avail_vcpus_xenstore(libxl__gc *gc, uint32_t domid,
+ unsigned int max_vcpus,
+ libxl_bitmap *map)
+{
+int rc;
+unsigned int i;
+const char *dompath;
+
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+for (i = 0; i < max_vcpus; i++) {
+const char *path = GCSPRINTF("%s/cpu/%u/availability", dompath, i);
+const char *content = libxl__xs_read(gc, XBT_NULL, path);
+if (!strncmp(content, "online", strlen("online")))
+libxl_bitmap_set(map, i);
+}
+
+rc = 0;
+out:
+return rc;
+}
+
int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid,
libxl_domain_config *d_config)
{
@@ -7270,6 +7321,46 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx,
uint32_t domid,
libxl_dominfo_dispose(&info);
}
+/* VCPUs */
+{
+libxl_bitmap *map = &d_config->b_info.avail_vcpus;
+unsigned int max_vcpus = d_config->b_info.max_vcpus;
+
+libxl_bitmap_dispose(map);
+libxl_bitmap_init(map);
+libxl_bitmap_alloc(CTX, map, max_vcpus);
+libxl_bitmap_set_none(map);
+
+switch (d_config->b_info.type) {
+case LIBXL_DOMAIN_TYPE_HVM:
+switch (d_config->b_info.device_model_version) {
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+rc = libxl__update_avail_vcpus_qmp(gc, domid,
+ max_vcpus, map);
+break;
+case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+rc = libxl__update_avail_vcpus_xenstore(gc, domid,
+max_vcpus, map);
+break;
+default:
+abort();
+}
+break;
+case LIBXL_DOMAIN_TYPE_PV:
+rc = libxl__update_avail_vcpus_xenstore(gc, domid,
+max_vcpus, map);
+break;
+default:
+abort();
+}
+
+if (rc) {
+LOG(ERROR, "fail to update available cpu map for domain %d",
domid);
+goto out;
+}
+}
+
/* Memory limits:
*
* Currently there are three memory limits:
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 07/06/16 12:13, Shannon Zhao wrote:
On 2016/6/7 19:05, Julien Grall wrote:
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
Is there any particular reason to expose the list of the tables outside
of the building code?
I would provide a single buffer with all the tables inside. Similar to
what you did for building the tables in the hypervisor.
When it loads these tables to guest memory space, it needs to update the
entries (pointing to other tables) of XSDT and also the
xsdt_physical_address in RSDP.
Why can't we load the ACPI tables at an hardcoded place in the memory
(for instance always at the beginning of the RAM)?
This would make the code a lot simpler and would avoid a duplication of
the same 5 lines for each tables in patch 14:
+xsdt = (struct acpi_xsdt_descriptor *)acpitablemap;
+memcpy(acpitablemap, dom->acpitable_blob->xsdt.table,
+ dom->acpitable_blob->xsdt.size);
[...]
+start += dom->acpitable_blob->xsdt.size;
+acpitablemap += dom->acpitable_blob->xsdt.size;
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
On 2016/6/7 19:19, Julien Grall wrote:
> Hello Shannon,
>
> On 31/05/16 06:02, Shannon Zhao wrote:
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index 9e99159..0fb4f69 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -3,6 +3,7 @@
>> #include "libxl_libfdt_compat.h"
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -880,13 +881,85 @@ out:
>> return rc;
>> }
>>
>> +static void make_acpi_header(struct acpi_table_header *h, const char
>> *sig,
>> + int len, uint8_t rev)
>> +{
>> +memcpy(&h->signature, sig, 4);
>> +h->length = len;
>> +h->revision = rev;
>> +memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6);
>> +memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4);
>> +memcpy(h->oem_table_id + 4, sig, 4);
>> +h->oem_revision = 1;
>> +memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
>> +h->asl_compiler_revision = 1;
>> +h->checksum = 0;
>
> Should not we compute the checksum here?
>
Sure.
>> +}
>> +
>> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
>> +{
>> +struct acpi_gtdt_descriptor *gtdt;
>> +
>> +gtdt = libxl__zalloc(gc, sizeof(*gtdt));
>> +
>> +gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
>> +gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> + |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
>
> There is no secure EL1 for guest, so this should be 0.
>
So why does DT add secure EL1 timer in make_timer_node()?
>> +gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
>> +gtdt->non_secure_el1_flags =
>> + (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> + |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
>> +gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
>> +gtdt->virtual_timer_flags =
>> + (ACPI_LEVEL_SENSITIVE <<
>> ACPI_GTDT_INTERRUPT_MODE)
>> + |(ACPI_ACTIVE_LOW <<
>> ACPI_GTDT_INTERRUPT_POLARITY);
>> +
>> +make_acpi_header(>dt->header, "GTDT", sizeof(*gtdt), 2);
>> +
>> +dom->acpitable_blob->gtdt.table = (void *)gtdt;
>> +/* Align to 64bit. */
>
> I am not sure what the comment is for.
>
Oops, I planed to make the length of these tables aligned to 64bit, but
it turns out it's unnecessary. And I forgot to delete this.
>> +dom->acpitable_blob->gtdt.size = sizeof(*gtdt);
>> +dom->acpitable_size += dom->acpitable_blob->gtdt.size;
>> +}
>
> Regards,
>
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
On 6/7/16 6:42 AM, M A Young wrote: > On Tue, 7 Jun 2016, George Dunlap wrote: > >> On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk >> wrote: >>> --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100 >>> +++ xen-4.7.0/config/StdGNU.mk 2016-04-15 23:01:40.978829756 +0100 >>> @@ -37,6 +37,12 @@ >>> >>> ifneq ($(debug),y) >>> CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars >>> +ifeq ($(XEN_TARGET_ARCH),x86_64) >>> +#might be cross-compiling so strip out possible x86_32 options >>> +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e >>> 's/-march=i686//g' -e 's/-mtune=atom//g') >>> +else >>> +CFLAGS += $(CFLAGS_EXTRA) >>> +endif >> >> Why the if? Under what circumstances is it actually appropriate to >> pass in those kinds of flags to the Xen build system? > > That may not be needed in general. It is something I added for Fedora as I > am cross-compiling the hypervisor as x86_64 to put in the i686 package > because ix86 hypervisors are no longer supported. > > Michael Young > I have to say looking at the change and looking at the reason there appears to be something very wrong with this. If you cross compile you shouldn't have to strip out your BUILD_ARCH's CFLAGS from your TARGET_ARCH's CFLAGS. It seems like somewhere those are getting crossed together and that needs to be fixed rather than patching Xen. If you think about it from x86 cross compiling for arm then this change doesn't make sense. e.g. We don't have to strip out x86 CFLAGS in Xen when we're building for arm. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 2016/6/7 19:27, Julien Grall wrote:
>
>
> On 07/06/16 12:13, Shannon Zhao wrote:
>>
>>
>> On 2016/6/7 19:05, Julien Grall wrote:
>>> Hello Shannon,
>>>
>>> On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h
b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
>>>
>>> Is there any particular reason to expose the list of the tables outside
>>> of the building code?
>>>
>>> I would provide a single buffer with all the tables inside. Similar to
>>> what you did for building the tables in the hypervisor.
>> When it loads these tables to guest memory space, it needs to update the
>> entries (pointing to other tables) of XSDT and also the
>> xsdt_physical_address in RSDP.
>
> Why can't we load the ACPI tables at an hardcoded place in the memory
> (for instance always at the beginning of the RAM)?
>
I think it's more reasonable to let the codes dynamically compute where
it should put these tables at like what it does for the devicetree blob.
And to an hardcoded place, can you make sure that kind of place is
always available and not used by others?
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
On 07/06/16 12:30, Shannon Zhao wrote:
On 2016/6/7 19:19, Julien Grall wrote:
On 31/05/16 06:02, Shannon Zhao wrote:
+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_gtdt_descriptor *gtdt;
+
+gtdt = libxl__zalloc(gc, sizeof(*gtdt));
+
+gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
+gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
There is no secure EL1 for guest, so this should be 0.
So why does DT add secure EL1 timer in make_timer_node()?
Because the DT binding mandates the secure EL1 IRQ. However this
interrupt will never be asserted by the virtual timer.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] nested vmx: Intercept guest rdmsr for MSR_IA32_VMX_VMFUNC
On 07/06/16 11:53, Euan Harris wrote: > On Tue, Jun 07, 2016 at 04:35:28AM -0600, Jan Beulich wrote: >>> @@ -2624,7 +2624,7 @@ static int vmx_msr_read_intercept(unsigned int msr, >>> uint64_t *msr_content) >>> __vmread(GUEST_IA32_DEBUGCTL, msr_content); >>> break; >>> case IA32_FEATURE_CONTROL_MSR: >>> -case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS: >>> +case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC: >>> if ( !nvmx_msr_read_intercept(msr, msr_content) ) >>> goto gp_fault; >>> break; >> ... retaining this code structure makes it likely that some future >> addition will lead to the same problem again. > The safest solution would be to whitelist the MSRs which Xen handles and > which the guest should be allowed to see, rather than blacklisting which > is essentially what is happening now. That would involve a substantial > change in the code, but aside from that is there any fundamental reason > why it would be a bad idea? I do have plans which will eventually turn all cpuid information and msrs visible to guests into a whitelist rather than a blacklist, but there is indeed a lot of infrastructure work required to make this happen. It is certainly the longterm plan. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
On 2016/6/7 19:36, Julien Grall wrote:
>
>
> On 07/06/16 12:30, Shannon Zhao wrote:
>> On 2016/6/7 19:19, Julien Grall wrote:
>>> On 31/05/16 06:02, Shannon Zhao wrote:
+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_gtdt_descriptor *gtdt;
+
+gtdt = libxl__zalloc(gc, sizeof(*gtdt));
+
+gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
+gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
>>>
>>> There is no secure EL1 for guest, so this should be 0.
>>>
>> So why does DT add secure EL1 timer in make_timer_node()?
>
> Because the DT binding mandates the secure EL1 IRQ. However this
> interrupt will never be asserted by the virtual timer.
Oh, right. But it's harmless. Anyway, I'll remove this.
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 07/06/16 12:35, Shannon Zhao wrote:
On 2016/6/7 19:27, Julien Grall wrote:
On 07/06/16 12:13, Shannon Zhao wrote:
On 2016/6/7 19:05, Julien Grall wrote:
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h
b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
Is there any particular reason to expose the list of the tables outside
of the building code?
I would provide a single buffer with all the tables inside. Similar to
what you did for building the tables in the hypervisor.
When it loads these tables to guest memory space, it needs to update the
entries (pointing to other tables) of XSDT and also the
xsdt_physical_address in RSDP.
Why can't we load the ACPI tables at an hardcoded place in the memory
(for instance always at the beginning of the RAM)?
I think it's more reasonable to let the codes dynamically compute where
it should put these tables at like what it does for the devicetree blob.
And to an hardcoded place, can you make sure that kind of place is
always available and not used by others?
Yes, the toolstack is in charge of the memory layout. So it can ensure
that no-one else is using this region.
My concern is, based on you patch #13, the ACPI tables are allocated
just after all the other modules. However, they cannot be relocated by
the kernel because they contain physical address. So they have to stay
in place for all the life of the domain.
We should put them in a place where it will not impact the memory
allocation of the guest. The start of the RAM is a good place for that.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
On 07/06/16 12:39, Shannon Zhao wrote:
On 2016/6/7 19:36, Julien Grall wrote:
On 07/06/16 12:30, Shannon Zhao wrote:
On 2016/6/7 19:19, Julien Grall wrote:
On 31/05/16 06:02, Shannon Zhao wrote:
+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_gtdt_descriptor *gtdt;
+
+gtdt = libxl__zalloc(gc, sizeof(*gtdt));
+
+gtdt->secure_el1_interrupt = GUEST_TIMER_PHYS_S_PPI;
+gtdt->secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
There is no secure EL1 for guest, so this should be 0.
So why does DT add secure EL1 timer in make_timer_node()?
Because the DT binding mandates the secure EL1 IRQ. However this
interrupt will never be asserted by the virtual timer.
Oh, right. But it's harmless. Anyway, I'll remove this.
Correct, but let's not expose things a guest could not use :).
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging
On Mon, Jun 06, 2016 at 03:47:37PM -0500, Doug Goldstein wrote: > On 6/6/16 5:12 AM, George Dunlap wrote: > > On 03/06/16 18:38, Andrew Cooper wrote: > >> On 01/06/16 15:00, Wei Liu wrote: > >>> Hi all > >>> > > > > > FWIW, the libvirt project has exactly the same problem, and they did the > > analog of what Wei is proposing -- they added a new daemon, virtlogd, to > > handle all the console and debug log rotation in a fashion resistant to > > DoSing. Without reading their discussion, it's reasonable to assume > > that using system logging was at least considered using system-level > > logging before deciding to write their own code. > > If I recall they use RPCs and the logs are generated as a best effort to > not block QEMU. > Does that mean it's more or less equivalent to O_NONBLOCK? Is that configurable? We might actually want to block in some cases. > > > > We already have a daemon to do logging of consoles; it just doesn't have > > any of the logrotate features that are needed to make it robust against > > DoS. There's no sense in having log rotation code in two places, so > > upgrading xenconsoled to do what virtlogd is doing makes more sense than > > say, either writing our own, or stealing virtlogd. > > What if we made xl / libxl really good at the limited scope of things it > should be good at and left the other bits to others. At this point it > seems like yet another feature that xl / libxl is gaining that matches > what libvirt does. Maybe an approach is something you appear to suggest > and just point people to virtlogd and ask the libvirt guys if they would > make it a separate package. Honestly it seems like xl could slim down > from a feature set perspective and focus on improving libxl / libvirt > interaction. That's something that the Xen community has been interested > in to better support OpenStack anyway. > To clarify: xenconsoled is not part of xl / libxl. I think it you're talking about xen toolstack in general. I think we can ask libvirt maintainers: 1. if it is possible to make virtlogd a separate package, 2. if they can maintain a stable interface. Then we can think about how to make sensible suggestions and provide a way for sysamdins to configure that. No matter what solution we end up with, the work to integrate that with xl / libxl is unavoidable. Wei. > Just my 2 cents. > > -- > Doug Goldstein > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 05/14] libxl/arm: Construct ACPI GTDT table
On Tue, Jun 07, 2016 at 10:48:36AM +0100, Stefano Stabellini wrote: > On Mon, 6 Jun 2016, Julien Grall wrote: > > Hello, > > > > On 06/06/16 13:04, Stefano Stabellini wrote: > > > On Mon, 6 Jun 2016, Julien Grall wrote: > > > > On 06/06/16 12:40, Stefano Stabellini wrote: > > > > > On Tue, 31 May 2016, Shannon Zhao wrote: > > > > > > From: Shannon Zhao > > > > > > > > > > ACPI tables for ARM guests should be user configurable: acpi=1 in the > > > > > VM > > > > > config file enables them, with default off. > > > > > > > > The VM system specification for ARM [1] mandates that both ACPI and DT > > > > should > > > > be provided and described the entire VM and its peripheral (see the > > > > section > > > > "Hardware Description"). > > > > > > > > Furthermore, the user may not know if the guest OS will use ACPI or DT > > > > For > > > > instance Redhat is using ACPI whilst Debian is using DT. > > > > > > > > So we have to provide both by default. However, 32-bit domain should > > > > only > > > > have > > > > Device-Tree table created. > > > > > > > > Anyway, the reason should have been described in the commit message. I > > > > would > > > > split this patch in two: introducing prepare ACPI and then GTDT table. > > > > So > > > > we > > > > can provide details in the commit message. > > > > > > All right, let me rephrase then: we should have a VMSPEC=on or off to > > > enable or disable compliance with the VM system specification for ARM. > > > (The good thing about specifications is that there are so many to choose > > > from.) With compliance disabled, we can avoid introducing ACPI tables > > > for the guest. > > > > > > Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and > > > more meaningful alias: "ACPI" :-) > > > > The VM specification introduces other components such as a SBSA UART > > emulation > > (which is not yet implemented by Xen). > > > > Do we want an option for each components? > > This is a good point. If one wants to avoid ACPI then she probably would > want to avoid SBSA UART emulation too. So maybe after all it might be > better to have a single > > vm_system_spec=1/0 > > option? I am OK with both having multiple options or just one. If the user is not supposed to pick and choose then using one is fine. We probably don't want to expose such capability anyway. Is the spec going to be updated at some point? Maybe make it some sort of version number? Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
Hello Shannon, On 07/06/16 12:42, Julien Grall wrote: Is there any particular reason to expose the list of the tables outside of the building code? I would provide a single buffer with all the tables inside. Similar to what you did for building the tables in the hypervisor. When it loads these tables to guest memory space, it needs to update the entries (pointing to other tables) of XSDT and also the xsdt_physical_address in RSDP. Why can't we load the ACPI tables at an hardcoded place in the memory (for instance always at the beginning of the RAM)? I think it's more reasonable to let the codes dynamically compute where it should put these tables at like what it does for the devicetree blob. And to an hardcoded place, can you make sure that kind of place is always available and not used by others? Yes, the toolstack is in charge of the memory layout. So it can ensure that no-one else is using this region. My concern is, based on you patch #13, the ACPI tables are allocated just after all the other modules. However, they cannot be relocated by the kernel because they contain physical address. So they have to stay in place for all the life of the domain. We should put them in a place where it will not impact the memory allocation of the guest. The start of the RAM is a good place for that. I though a bit more on this suggestion. If the ACPI tables are put at the beginning of the RAM, a guest may not be able to use super page. I would suggest to move the ACPI table out of the real RAM to avoid any potential issue with the kernel memory allocation. For instance we could define a IPA range to be use for ACPI (e.g 0x2000 - 0x2020) and expose to the guest using the ACPI_NVS type in the UEFI memory map. Any opinion on this? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 2016/6/7 19:42, Julien Grall wrote:
>
>
> On 07/06/16 12:35, Shannon Zhao wrote:
>>
>>
>> On 2016/6/7 19:27, Julien Grall wrote:
>>>
>>>
>>> On 07/06/16 12:13, Shannon Zhao wrote:
On 2016/6/7 19:05, Julien Grall wrote:
> Hello Shannon,
>
> On 31/05/16 06:02, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
>> for ARM VM. So only add placeholders for them here.
>>
>> Signed-off-by: Shannon Zhao
>> ---
>> tools/libxc/include/xc_dom.h | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/tools/libxc/include/xc_dom.h
>> b/tools/libxc/include/xc_dom.h
>> index 6cb10c4..0fe54dd 100644
>> --- a/tools/libxc/include/xc_dom.h
>> +++ b/tools/libxc/include/xc_dom.h
>> @@ -56,6 +56,20 @@ struct xc_dom_phys {
>> xen_pfn_t count;
>> };
>>
>> +struct acpitable {
>> +void *table;
>> +size_t size;
>> +};
>> +
>> +struct acpitable_blob {
>> +struct acpitable rsdp;
>> +struct acpitable xsdt;
>> +struct acpitable gtdt;
>> +struct acpitable madt;
>> +struct acpitable fadt;
>> +struct acpitable dsdt;
>> +};
>
> Is there any particular reason to expose the list of the tables
> outside
> of the building code?
>
> I would provide a single buffer with all the tables inside. Similar to
> what you did for building the tables in the hypervisor.
When it loads these tables to guest memory space, it needs to update
the
entries (pointing to other tables) of XSDT and also the
xsdt_physical_address in RSDP.
>>>
>>> Why can't we load the ACPI tables at an hardcoded place in the memory
>>> (for instance always at the beginning of the RAM)?
>>>
>> I think it's more reasonable to let the codes dynamically compute where
>> it should put these tables at like what it does for the devicetree blob.
>>
>> And to an hardcoded place, can you make sure that kind of place is
>> always available and not used by others?
>
> Yes, the toolstack is in charge of the memory layout. So it can ensure
> that no-one else is using this region.
>
> My concern is, based on you patch #13, the ACPI tables are allocated
> just after all the other modules. However, they cannot be relocated by
> the kernel because they contain physical address. So they have to stay
> in place for all the life of the domain.
>
No, this doesn't like what you say. UEFI will install and relocate the
ACPI tables again for guest kernel. That means the ACPI tables guest
gets are not from the original place where toolstack puts them at.
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 07/06/16 12:59, Shannon Zhao wrote:
On 2016/6/7 19:42, Julien Grall wrote:
On 07/06/16 12:35, Shannon Zhao wrote:
On 2016/6/7 19:27, Julien Grall wrote:
On 07/06/16 12:13, Shannon Zhao wrote:
On 2016/6/7 19:05, Julien Grall wrote:
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT, DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h
b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
Is there any particular reason to expose the list of the tables
outside
of the building code?
I would provide a single buffer with all the tables inside. Similar to
what you did for building the tables in the hypervisor.
When it loads these tables to guest memory space, it needs to update
the
entries (pointing to other tables) of XSDT and also the
xsdt_physical_address in RSDP.
Why can't we load the ACPI tables at an hardcoded place in the memory
(for instance always at the beginning of the RAM)?
I think it's more reasonable to let the codes dynamically compute where
it should put these tables at like what it does for the devicetree blob.
And to an hardcoded place, can you make sure that kind of place is
always available and not used by others?
Yes, the toolstack is in charge of the memory layout. So it can ensure
that no-one else is using this region.
My concern is, based on you patch #13, the ACPI tables are allocated
just after all the other modules. However, they cannot be relocated by
the kernel because they contain physical address. So they have to stay
in place for all the life of the domain.
No, this doesn't like what you say. UEFI will install and relocate the
ACPI tables again for guest kernel. That means the ACPI tables guest
gets are not from the original place where toolstack puts them at.
Why does UEFI need to relocate the ACPI tables?
Anyway, you rely on the UEFI firmware to always relocating the tables.
What would happen if they decide to remove this behavior?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Questions about virtlogd
Hello libvirt maintainers, Libvirt implements virtlogd in version 1.3 which now handles logging for QEMU process. I am wondering if it is possible to make it a separate package and maintain stable interfaces for external users? This is related to XSA-180 / CVE-2014-3672 (unrestricted QEMU logging). We are evaluating using virtlogd vs writing our own solution. I believe there are still some open questions on how exactly the integration could be done but let's worry about that later. Thanks Wei. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3672 [1] http://xenbits.xen.org/xsa/advisory-180.html ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 95332: regressions - FAIL
flight 95332 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95332/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. vs. 95234 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 95234 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 95234 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 95234 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95234 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 build-amd64-rumpuserxen 6 xen-buildfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 551948806424f8b63b16b9c1bb1b2a792edc9193 baseline version: xen 01311b90ced670a8025690eaa13ab461d1bc5e67 Last test of basis95234 2016-06-03 10:52:57 Z4 days Testing same since95332 2016-06-06 15:12:10 Z0 days1 attempts People who touched revisions under test: Ian Jackson jobs: build-amd64-xend pass build-i386-xend 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64fail 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-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail te
Re: [Xen-devel] [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi
On Mon, Jun 06, 2016 at 12:09:21PM -0400, Boris Ostrovsky wrote:
> On 06/06/2016 09:05 AM, Jan Beulich wrote:
> On 06.04.16 at 03:25, wrote:
> >> .gitignore| 8
> >>
> >> tools/firmware/hvmloader/Makefile | 3 +--
> >> tools/firmware/hvmloader/smbios.c | 1 +
> >> tools/firmware/rombios/32bit/Makefile | 2 +-
> >> tools/firmware/rombios/32bit/tcgbios/Makefile | 2 +-
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile| 6
> >> +++---
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README | 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h | 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c | 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl| 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c | 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl | 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl | 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl | 0
> >> .../firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl | 0
> >> .../hvmloader/acpi => xen/common/libacpi}/static_tables.c | 0
> >> {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h | 0
> >> 17 files changed, 11 insertions(+), 11 deletions(-)
> > As mentioned before, new placement subject to determination
> > whether this is to eventually be used by the hypervisor.
>
>
> Roger, when do you think you'll be able to see whether dom0 builder will
> use this? I can start working on v1 with assumption that this will be
> used by hypervisor. We can drop the last patch (and modify this one to
> move acpi to somewhere in tools) if it becomes clear that hypervisor
> does not want it.
What we need to do is quite similar to what ARM does, and they seem to
prefer to have different ACPI code for Dom0/DomU, so I'm quite sure we could
do the same for x86 also. FWIW, when Boris and I discussed this we though it
would be better to have a single place where all the ACPI code resides, both
to create tables or to modify them.
Would it be a lot of work to leave it in tools/ for the time being and move
it later if we see that we could benefit from merging both? Or maybe leave
it in xen/common without linking it with the hypervisor just yet (but that
would need sorting out later anyway).
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 2016/6/7 20:02, Julien Grall wrote: > Hello Shannon, > > On 07/06/16 12:42, Julien Grall wrote: >> Is there any particular reason to expose the list of the tables >> outside >> of the building code? >> >> I would provide a single buffer with all the tables inside. >> Similar to >> what you did for building the tables in the hypervisor. > When it loads these tables to guest memory space, it needs to update > the > entries (pointing to other tables) of XSDT and also the > xsdt_physical_address in RSDP. Why can't we load the ACPI tables at an hardcoded place in the memory (for instance always at the beginning of the RAM)? >>> I think it's more reasonable to let the codes dynamically compute where >>> it should put these tables at like what it does for the devicetree blob. >>> >>> And to an hardcoded place, can you make sure that kind of place is >>> always available and not used by others? >> >> Yes, the toolstack is in charge of the memory layout. So it can ensure >> that no-one else is using this region. >> >> My concern is, based on you patch #13, the ACPI tables are allocated >> just after all the other modules. However, they cannot be relocated by >> the kernel because they contain physical address. So they have to stay >> in place for all the life of the domain. >> >> We should put them in a place where it will not impact the memory >> allocation of the guest. The start of the RAM is a good place for that. > > I though a bit more on this suggestion. If the ACPI tables are put at > the beginning of the RAM, a guest may not be able to use super page. > > I would suggest to move the ACPI table out of the real RAM to avoid any > potential issue with the kernel memory allocation. > > For instance we could define a IPA range to be use for ACPI (e.g > 0x2000 - 0x2020) and expose to the guest using the ACPI_NVS type > in the UEFI memory map. > > Any opinion on this? No, this will not work. UEFI will control the memory map by itself. -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 2016/6/7 20:06, Julien Grall wrote:
>
>
> On 07/06/16 12:59, Shannon Zhao wrote:
>>
>>
>> On 2016/6/7 19:42, Julien Grall wrote:
>>>
>>>
>>> On 07/06/16 12:35, Shannon Zhao wrote:
On 2016/6/7 19:27, Julien Grall wrote:
>
>
> On 07/06/16 12:13, Shannon Zhao wrote:
>>
>>
>> On 2016/6/7 19:05, Julien Grall wrote:
>>> Hello Shannon,
>>>
>>> On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT,
DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h
b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
>>>
>>> Is there any particular reason to expose the list of the tables
>>> outside
>>> of the building code?
>>>
>>> I would provide a single buffer with all the tables inside.
>>> Similar to
>>> what you did for building the tables in the hypervisor.
>> When it loads these tables to guest memory space, it needs to update
>> the
>> entries (pointing to other tables) of XSDT and also the
>> xsdt_physical_address in RSDP.
>
> Why can't we load the ACPI tables at an hardcoded place in the memory
> (for instance always at the beginning of the RAM)?
>
I think it's more reasonable to let the codes dynamically compute where
it should put these tables at like what it does for the devicetree
blob.
And to an hardcoded place, can you make sure that kind of place is
always available and not used by others?
>>>
>>> Yes, the toolstack is in charge of the memory layout. So it can ensure
>>> that no-one else is using this region.
>>>
>>> My concern is, based on you patch #13, the ACPI tables are allocated
>>> just after all the other modules. However, they cannot be relocated by
>>> the kernel because they contain physical address. So they have to stay
>>> in place for all the life of the domain.
>>>
>> No, this doesn't like what you say. UEFI will install and relocate the
>> ACPI tables again for guest kernel. That means the ACPI tables guest
>> gets are not from the original place where toolstack puts them at.
>
> Why does UEFI need to relocate the ACPI tables?
>
That's its own mechanism I think and UEFI wants all the memory maps
under its control. And it's same for QEMU(x86 and ARM) and also for Xen
on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
is used for x86 Xen DomU.
> Anyway, you rely on the UEFI firmware to always relocating the tables.
> What would happen if they decide to remove this behavior?
Eh, I don't believe this would happen.
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size
On 07/06/16 13:32, Shannon Zhao wrote:
On 2016/6/7 20:06, Julien Grall wrote:
On 07/06/16 12:59, Shannon Zhao wrote:
On 2016/6/7 19:42, Julien Grall wrote:
On 07/06/16 12:35, Shannon Zhao wrote:
On 2016/6/7 19:27, Julien Grall wrote:
On 07/06/16 12:13, Shannon Zhao wrote:
On 2016/6/7 19:05, Julien Grall wrote:
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently it only needs ACPI table RSDP, XSDT, GTDT, MADT, FADT,
DSDT
for ARM VM. So only add placeholders for them here.
Signed-off-by: Shannon Zhao
---
tools/libxc/include/xc_dom.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h
b/tools/libxc/include/xc_dom.h
index 6cb10c4..0fe54dd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -56,6 +56,20 @@ struct xc_dom_phys {
xen_pfn_t count;
};
+struct acpitable {
+void *table;
+size_t size;
+};
+
+struct acpitable_blob {
+struct acpitable rsdp;
+struct acpitable xsdt;
+struct acpitable gtdt;
+struct acpitable madt;
+struct acpitable fadt;
+struct acpitable dsdt;
+};
Is there any particular reason to expose the list of the tables
outside
of the building code?
I would provide a single buffer with all the tables inside.
Similar to
what you did for building the tables in the hypervisor.
When it loads these tables to guest memory space, it needs to update
the
entries (pointing to other tables) of XSDT and also the
xsdt_physical_address in RSDP.
Why can't we load the ACPI tables at an hardcoded place in the memory
(for instance always at the beginning of the RAM)?
I think it's more reasonable to let the codes dynamically compute where
it should put these tables at like what it does for the devicetree
blob.
And to an hardcoded place, can you make sure that kind of place is
always available and not used by others?
Yes, the toolstack is in charge of the memory layout. So it can ensure
that no-one else is using this region.
My concern is, based on you patch #13, the ACPI tables are allocated
just after all the other modules. However, they cannot be relocated by
the kernel because they contain physical address. So they have to stay
in place for all the life of the domain.
No, this doesn't like what you say. UEFI will install and relocate the
ACPI tables again for guest kernel. That means the ACPI tables guest
gets are not from the original place where toolstack puts them at.
Why does UEFI need to relocate the ACPI tables?
That's its own mechanism I think and UEFI wants all the memory maps
under its control. And it's same for QEMU(x86 and ARM) and also for Xen
on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
is used for x86 Xen DomU.
UEFI cannot control the memory map because it is not capable to know
what a region is used for (such as magic pages, grant table...).
In the case of domU for x86, the ACPI table are located in predefine
physical address by hvmloader. I really don't see any reason that would
prevent us to do the same on ARM.
If the UEFI firmware wants to relocate the tables, then fine. But we
should also think about any firmware which may not relocate the tables.
Anyway, you rely on the UEFI firmware to always relocating the tables.
What would happen if they decide to remove this behavior?
Eh, I don't believe this would happen.
You seem very optimistic. Xen does not rely on a specific UEFI
implementation nor how a guest will behave. We have to predict what
could happen and find the best way to do it.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 4/4] qemu-xen-dir/hw/block: Cache local buffers used in grant copy
On Thu, 2016-06-02 at 16:19 +0200, Roger Pau Monné wrote:
> On Tue, May 31, 2016 at 06:44:58AM +0200, Paulina Szubarczyk wrote:
> > If there are still pending requests the buffers are not free() but
> > cached in an array of a size max_request*BLKIF_MAX_SEGMENTS_PER_REQUEST
> >
> > ---
> > hw/block/xen_disk.c | 60
> > +
> > 1 file changed, 47 insertions(+), 13 deletions(-)
> >
> > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> > index 43cd9c9..cf80897 100644
> > --- a/hw/block/xen_disk.c
> > +++ b/hw/block/xen_disk.c
> > @@ -125,6 +125,10 @@ struct XenBlkDev {
> > /* */
> > gbooleanfeature_discard;
> >
> > +/* request buffer cache */
> > +void**buf_cache;
> > +int buf_cache_free;
>
> Have you checked if there's some already available FIFO queue structure that
> you can use?
>
> Glib Trash Stacks looks like a suitable candidate:
>
> https://developer.gnome.org/glib/stable/glib-Trash-Stacks.html
Persistent regions are using a single-link-list GSList and I was
thinking that using that structure here will be better since from the
link you send comes out that Trash-Stacks are deprecated from 2.48.
But I have some problems with debuging qemu-system-i386. gdb is not able
to load symbols, it informs "qemu-system-i386...(no debugging symbols
found)...done." It was not an issue earlier and I have tried to run
configure with --enable-debug before the build as well as setting
'strip_opt="yes"'.
>
> > +
> > /* qemu block driver */
> > DriveInfo *dinfo;
> > BlockBackend*blk;
> > @@ -284,12 +288,16 @@ err:
> > return -1;
> > }
> >
> > -
> > -static void* get_buffer(void) {
> > +static void* get_buffer(struct XenBlkDev *blkdev) {
> > void *buf;
> >
> > -buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE,
> > +if(blkdev->buf_cache_free <= 0) {
> > +buf = mmap(NULL, 1 << XC_PAGE_SHIFT, PROT_READ | PROT_WRITE,
> > MAP_SHARED | MAP_ANONYMOUS, -1, 0);
> > +} else {
> > +blkdev->buf_cache_free--;
> > +buf = blkdev->buf_cache[blkdev->buf_cache_free];
> > +}
> >
> > if (unlikely(buf == MAP_FAILED))
> > return NULL;
> > @@ -301,21 +309,40 @@ static int free_buffer(void* buf) {
> > return munmap(buf, 1 << XC_PAGE_SHIFT);
> > }
> >
> > -static int free_buffers(void** page, int count)
> > +static int free_buffers(void** page, int count, struct XenBlkDev *blkdev)
> > {
> > -int i, r = 0;
> > +int i, put_buf_cache = 0, r = 0;
> > +
> > +if (blkdev->more_work && blkdev->requests_inflight < max_requests) {
>
> Shouldn't this be <=?
>
> Or else you will only cache at most 341 pages instead of the maximum
> number of pages that can be in-flight (352).
At the moment when the request is completing and freeing the pages it is
still a part of in-flight requests and then I think there should not be
scheduled more then max_request-1 of others.
Paulina
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 06/14] libxl/arm: Construct ACPI FADT table
Hello Shannon,
It just occurred to me that the way to build the ACPI tables, I am not
speaking about the value, is very similar to what QEMU does.
Perhaps, we should copy the copyright from QEMU in libxl_arm.c. In this
case, moving the ACPI code in a separate file would be the best.
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0fb4f69..c3b8fb4 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -922,6 +922,28 @@ static void make_acpi_gtdt(libxl__gc *gc, struct
xc_dom_image *dom)
dom->acpitable_size += dom->acpitable_blob->gtdt.size;
}
+static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_fadt_descriptor *fadt;
+
+fadt = libxl__zalloc(gc, sizeof(*fadt));
+
+/* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */
+fadt->flags = 1 << ACPI_FADT_F_HW_REDUCED_ACPI;
+fadt->arm_boot_flags = (1 << ACPI_FADT_ARM_USE_PSCI_G_0_2) |
+ (1 << ACPI_FADT_ARM_PSCI_USE_HVC);
+
+/* ACPI v5.1 (fadt->revision.fadt->minor_revision) */
+fadt->minor_revision = 0x1;
+
+make_acpi_header(&fadt->header, "FACP", sizeof(*fadt), 5);
+
+dom->acpitable_blob->fadt.table = (void *)fadt;
pointless cast.
+/* Align to 64bit. */
I am not sure what the comment is for.
+dom->acpitable_blob->fadt.size = sizeof(*fadt);
+dom->acpitable_size += dom->acpitable_blob->fadt.size;
+}
+
static int prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
libxl__domain_build_state *state,
struct xc_dom_image *dom)
@@ -943,6 +965,7 @@ static int prepare_acpi(libxl__gc *gc,
libxl_domain_build_info *info,
dom->acpitable_size = 0;
make_acpi_gtdt(gc, dom);
+make_acpi_fadt(gc, dom);
return 0;
}
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2] xen/arm: build: add missed dependency for head.S
On Tue, Jun 07, 2016 at 12:34:43PM +0800, Wei Chen wrote: > In current Xen build rules, the build system will only check the > dependencies in current folder and obj-y generated dependencies > in other folder. > > But Makefile may add some objects to ALL_OBJS. These objects may > be not in the same folder as Makefile. Use arch/arm/Makefile as > an example: > ALL_OBJS := $(TARGET_SUBARCH)/head.o > > The head.o is not in the same folder as Makefile and is not listed > in obj-y. So, when we update the header files that had been included > in head.S. The build system would not check the dependency of head.S. > The head.S would not be re-compiled. > > In this patch, we will get objects added by Makefile and add their > dependencies to check list. > > Signed-off-by: Wei Chen > --- > v1 -> v2: > - Use a generic method instead of changing Makefiles > --- > xen/Rules.mk | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/xen/Rules.mk b/xen/Rules.mk > index 961d533..fb3087c 100644 > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -95,12 +95,21 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk > include Makefile > > DEPS = .*.d > + > +# In obj-y and ALL_OBJS, there may have some objects are not in the You are missing a verb here. I think you mean to say 'there may be some objects which are not in the' > +# same folder as Makefile, so we have to use gendep to generate > +# dependencies for them. > +DEP_OBJS = $(obj-y) > + > +# Extract objects from ALL_OBJS added by Makefile. > +DEP_OBJS += $(filter-out %built_in.o,$(ALL_OBJS)) > + > define gendep > ifneq ($(1),$(subst /,:,$(1))) > DEPS += $(dir $(1)).$(notdir $(1)).d > endif > endef > -$(foreach o,$(filter-out %/,$(obj-y)),$(eval $(call gendep,$(o > +$(foreach o,$(filter-out %/,$(DEP_OBJS)),$(eval $(call gendep,$(o > > # Ensure each subdirectory has exactly one trailing slash. > subdir-n := $(patsubst %,%/,$(patsubst %/,%,$(subdir-n) $(subdir-))) > -- > 2.7.4 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] Questions about virtlogd
On Tue, Jun 07, 2016 at 01:11:53PM +0100, Wei Liu wrote: > Hello libvirt maintainers, > > Libvirt implements virtlogd in version 1.3 which now handles logging > for QEMU process. I am wondering if it is possible to make it a > separate package and maintain stable interfaces for external users? Ok, so you're essentially asking for us to create a libvirt-logd.so library for talking to virtlogd, which would basically contain the code currently in src/logging/log_manager.c That's certainly possible from a technical POV, but the real question is whether we want to do that from a policy POV, given the greater support implications that has. > This is related to XSA-180 / CVE-2014-3672 (unrestricted QEMU > logging). We are evaluating using virtlogd vs writing our own > solution. I believe there are still some open questions on how exactly > the integration could be done but let's worry about that later. I must admit I'm not familiar with the division of responsibility for managing QEMU between the Xen provided libxl library(s) and the libvirt libxl driver code. Naively I would expect the libvirt libxl driver code to deal with virtlogd and then configure the Xen libxl library / QEMU accordingly. Your request seems to imply that you will need the Xen libxl library to directly talk to virtlogd instead. Is there any way in which it would be practical for the libvirt libxl driver to talk to virtlogd to acquire the file descriptors to use and pass those file descriptors down to the libxl library ? Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] libxenvchan license (lGPLv2.1) and xen/include/public/COPYING license?
On Mon, Jun 06, 2016 at 05:36:23PM -0400, Konrad Rzeszutek Wilk wrote: > Hey! +CC Lars. > > I picked the list of people on this email from the git log on > tools/misc/libvchan/ > (albeit this is about xen/include/public/io/libxenvchan.h). > > The problem is that the 'COPYING' file in the root directory of Xen source > says: > > " > > Licensing Exceptions (the relaxed BSD-style license) > > > > > > For the convenience of users and those who are porting OSes to run as > > Xen guests, certain files in this repository are not subject to the > > GPL when distributed separately or included in software packages > > outside this repository." > > The libxenvchan.h header file is an Lesser GPLv2.1. Which would > imply that one could ignore the giant @section LICENSE in the libxenvchan.h > and treat it as non-GPL... > > But to make the matters more complicated the ./COPYING files continues > with: > > "Instead we specify a much more relaxed > BSD-style license. Affected files include the Xen interface headers > > (xen/include/public/COPYING), MiniOS (extras/mini-os) and various > > drivers, support functions and header files within Xen-aware Linux > > source trees. In all such cases, license terms are stated at the top > > of the file or in a COPYING file in the same directory. Note that > > _any_ file that is modified and then distributed within a Linux kernel > > is still subject to the GNU GPL. " > > Great, so if I break this up: > > a) "Xen interface headers (xen/include/public/COPYING)," > b) "MiniOS (..) and various drivers," > c) "support functions and header files with Xen-aware Linux > source trees." > > Well, libxenvchan is a). > > What? > > Yes, if I look in xen/include/public/COPYING it says: > > " > XEN NOTICE > == > > This copyright applies to all files within this subdirectory and its > subdirectories: > include/public/*.h > include/public/hvm/*.h > include/public/io/*.h > > The intention is that these files can be freely copied into the source > tree of an operating system when porting that OS to run on Xen. Doing > so does *not* cause the OS to become subject to the terms of the GPL > " > > and libxenvchan.h is in ./xen/include/public/io/libxenvchan.h > > Also it is in FreeBSD (source tree): ./sys/xen/interface/io/libxenvchan.h > > That looks to be an oversigh. The commit that introduced the file is: > commit 1a16a3351ff2f2cf9f0cc0a27c89a0652eb8dfb4 > Author: Daniel De Graaf > Date: Thu Oct 6 19:44:40 2011 +0100 > > libvchan: interdomain communications library > > As such I was wondering if the folks who wrote/checked the file in > could weight in on what their intention was in regards to this file? > > Thanks! > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 08/14] libxl/arm: Construct ACPI MADT table
Hello Shannon,
On 31/05/16 06:03, Shannon Zhao wrote:
From: Shannon Zhao
According to the gic version, construct the MADT table.
NIT: s/gic/GIC/
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 107
1 file changed, 107 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 7949635..f72f692 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -958,11 +958,115 @@ static void make_acpi_dsdt(libxl__gc *gc, struct
xc_dom_image *dom)
dom->acpitable_size += ROUNDUP(dom->acpitable_blob->dsdt.size, 3);
}
+static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
+{
+uint32_t i;
+uint64_t mpidr_aff;
+struct acpi_madt_generic_interrupt *gicc = table;
+
+for (i = 0; i < nr_cpus; i++) {
+gicc->type = ACPI_APIC_GENERIC_INTERRUPT;
+gicc->length = sizeof(*gicc);
+gicc->base_address = gicc_base;
+gicc->cpu_interface_number = i;
+
+/*
+ * We will use AFF0 and AFF1 when constructing the MPIDR value of the
+ * guest at the moment, for it is enough for the current max vcpu
+ * number.
+ */
+mpidr_aff = (i & 0x0f) | (((i >> 4) & 0xff) << 8);
I would prefer if you introduce an helper to compute the MPIDR to avoid
open coding in 2 places (DT and ACPI).
+gicc->arm_mpidr = mpidr_aff;
+gicc->uid = i;
I don't see any code to create the associated processor device object in
the DSDT.
+gicc->flags = 1;
Please use a define here.
+
+gicc += 1;
+}
+}
+
+static void make_acpi_madt_gicd(void *table, uint64_t gicd_base,
+uint8_t gic_version)
+{
+struct acpi_madt_generic_distributor *gicd = table;
+
+gicd->type = ACPI_APIC_GENERIC_DISTRIBUTOR;
+gicd->length = sizeof(*gicd);
+gicd->base_address = gicd_base;
+gicd->version = gic_version;
This field is has been added with ACPI 5.1 errata, which technically is
not ACPI 5.1.
I don't mind if you use it, however it would need a comment to explain
that this field had no other meaning before...
+}
+
+static void make_acpi_madt_gicr(void *table, uint64_t gicr_base,
+uint64_t gicr_size)
+{
+struct acpi_madt_generic_redistributor *gicr = table;
+
+gicr->type = ACPI_APIC_GENERIC_REDISTRIBUTOR;
+gicr->length = sizeof(*gicr);
+gicr->base_address = gicr_base;
+gicr->range_length = gicr_size;
+}
+
+static int make_acpi_madt(libxl__gc *gc, struct xc_dom_image *dom, int nr_cpus,
+ xc_domain_configuration_t *xc_config)
+{
+uint32_t size;
+void *table;
+struct acpi_madt_descriptor *madt;
+
+switch (xc_config->gic_version) {
+case XEN_DOMCTL_CONFIG_GIC_V2:
+size = sizeof(struct acpi_madt_descriptor) +
+ sizeof(struct acpi_madt_generic_interrupt) * nr_cpus +
+ sizeof(struct acpi_madt_generic_distributor);
+table = libxl__zalloc(gc, size);
+madt = (struct acpi_madt_descriptor *)table;
+
+table += sizeof(struct acpi_madt_descriptor);
+make_acpi_madt_gicc(table, nr_cpus, GUEST_GICC_BASE);
+
+table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
+make_acpi_madt_gicd(table, GUEST_GICD_BASE, 2);
+break;
+case XEN_DOMCTL_CONFIG_GIC_V3:
+size = sizeof(struct acpi_madt_descriptor) +
+ sizeof(struct acpi_madt_generic_interrupt) * nr_cpus +
+ sizeof(struct acpi_madt_generic_distributor) +
+ sizeof(struct acpi_madt_generic_redistributor);
+table = libxl__zalloc(gc, size);
+madt = (struct acpi_madt_descriptor *)table;
+
+table += sizeof(struct acpi_madt_descriptor);
+make_acpi_madt_gicc(table, nr_cpus, 0);
+
+table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
+make_acpi_madt_gicd(table, GUEST_GICV3_GICD_BASE, 3);
+
+table += sizeof(struct acpi_madt_generic_distributor);
+make_acpi_madt_gicr(table, GUEST_GICV3_GICR0_BASE,
+GUEST_GICV3_GICR0_SIZE);
+break;
+default:
+LOG(ERROR, "Unknown GIC version %s",
+gicv_to_string(xc_config->gic_version));
+return ERROR_FAIL;
+}
+
+make_acpi_header(&madt->header, "APIC", size, 3);
+
+dom->acpitable_blob->madt.table = (void *)madt;
Pointless cast.
+/* Align to 64bit. */
Pointless comment.
+dom->acpitable_blob->madt.size = size;
+dom->acpitable_size += dom->acpitable_blob->madt.size;
+
+return 0;
+}
+
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 crash
On 6/7/2016 5:53 AM, Ian Jackson wrote:
Aaron Cornelius writes ("Re: [Xen-devel] Xen 4.7 crash"):
We realized that we had forgotten to remove the domain from the
permissions list when the domain is deleted (which would cause the error
we saw). The application was updated to remove the domain from the
permissions list:
1. retrieve the permissions with xs_get_permissions()
2. find the domain ID that is being deleted
3. memmove() the remaining domains down by 1 to "delete" the old domain
from the permissions list
4. update the permissions with xs_set_permissions()
After we made that change, a load test over the weekend confirmed that
the Xen crash no longer happens. We checked this morning first thing
and confirmed that without this change the crash reliably occurs.
This is rather odd behaviour. I don't think xenstored should hang
onto the domain's xs ring page just because the domain is still
mentioned in a permission list.
But it may do. I haven't checked the code. Are you using the
ocaml xenstored (oxenstored) or the C one ?
I didn't remember specifying anything special when building the xen
tools, but I did run into troubles where the ocaml tools appeared to
conflict with the opam installed mirage packages and libraries. Running
"sudo make dist-install" command installs the ocaml libraries as root
which made using opam difficult. So I did disable the ocaml tools
during my build.
I double checked and confirmed that the C version of xenstored was
built. We will try to test the failure scenario with oxenstored to see
if it behaves any differently.
- Aaron
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 07/14] libxl/arm: Construct ACPI DSDT table
Hello Shannon,
On 31/05/16 06:02, Shannon Zhao wrote:
From: Shannon Zhao
Currently there is only the table header in DSDT table.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index c3b8fb4..7949635 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -944,6 +944,20 @@ static void make_acpi_fadt(libxl__gc *gc, struct
xc_dom_image *dom)
dom->acpitable_size += dom->acpitable_blob->fadt.size;
}
+static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_table_header *dsdt;
+
+/* Currently there is only the table header in DSDT table. */
What about the processor device objects?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RESEND 12/14] libxl/arm: Add ACPI module
Hello Shannon, On 31/05/16 06:03, Shannon Zhao wrote: From: Shannon Zhao Add the ARM Multiboot module for ACPI, so UEFI can get the base address of ACPI tables from it. This new binding/compatible needs to be formalized in docs/misc/arm/device-tree. Signed-off-by: Shannon Zhao --- tools/libxl/libxl_arm.c | 20 1 file changed, 20 insertions(+) diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c index 13259f8..e7cb578 100644 --- a/tools/libxl/libxl_arm.c +++ b/tools/libxl/libxl_arm.c @@ -285,6 +285,26 @@ static int make_chosen_node(libxl__gc *gc, void *fdt, bool ramdisk, if (res) return res; } +res = fdt_begin_node(fdt, "modules"); +if (res) return res; + +res = fdt_begin_node(fdt, "module@0"); +if (res) return res; + +res = fdt_property_compat(gc, fdt, 2, "xen,linux-acpi", The ACPI blob is not Linux specific. What about "xen,guest-acpi"? + "xen,multiboot-module"); +if (res) return res; + +res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS, +1, 0, 0); +if (res) return res; + +res = fdt_end_node(fdt); +if (res) return res; + +res = fdt_end_node(fdt); +if (res) return res; + res = fdt_end_node(fdt); if (res) return res; Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
On Tue, Jun 7, 2016 at 12:33 PM, Doug Goldstein wrote: > On 6/7/16 6:42 AM, M A Young wrote: >> On Tue, 7 Jun 2016, George Dunlap wrote: >> >>> On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk >>> wrote: --- xen-4.7.0/config/StdGNU.mk.orig 2016-04-15 22:56:52.191227591 +0100 +++ xen-4.7.0/config/StdGNU.mk 2016-04-15 23:01:40.978829756 +0100 @@ -37,6 +37,12 @@ ifneq ($(debug),y) CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars +ifeq ($(XEN_TARGET_ARCH),x86_64) +#might be cross-compiling so strip out possible x86_32 options +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e 's/-march=i686//g' -e 's/-mtune=atom//g') +else +CFLAGS += $(CFLAGS_EXTRA) +endif >>> >>> Why the if? Under what circumstances is it actually appropriate to >>> pass in those kinds of flags to the Xen build system? >> >> That may not be needed in general. It is something I added for Fedora as I >> am cross-compiling the hypervisor as x86_64 to put in the i686 package >> because ix86 hypervisors are no longer supported. >> >> Michael Young >> > > I have to say looking at the change and looking at the reason there > appears to be something very wrong with this. If you cross compile you > shouldn't have to strip out your BUILD_ARCH's CFLAGS from your > TARGET_ARCH's CFLAGS. It seems like somewhere those are getting crossed > together and that needs to be fixed rather than patching Xen. But I think these are *in general* meant to be the TARGET_ARCH's cflags. Michael is building packages for 32-bit fedora, so the tools and everything actually do want to be 32-bit. It's just the hypervisor which is special -- it has to be compiled 64-bit even when building "32-bit" packages. So the -m32 needs to be filtered out of the TARGET_ARCH -- the question is whether it should be done in the makefiles, or in the RPM spec file. I'm inclined to say the latter. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] OvmfPkg: Add ACPI support for Virt Xen ARM
Hello Shannon,
On 31/05/16 05:59, Shannon Zhao wrote:
+EFI_STATUS
+EFIAPI
+GetXenArmAcpiRsdp (
+ OUT EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER **RsdpPtr
+ )
+{
+ VOID *Hob;
+ EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *RsdpStructurePtr;
+ VOID *DeviceTreeBase;
+ INT32 Node, Depth, Len;
+ CONST CHAR8*Type;
+ CONST VOID *RegProp;
+
+ RsdpStructurePtr = NULL;
+ //
+ // Get the RSDP structure address from DeviceTree
+ //
+ Hob = GetFirstGuidHob(&gFdtHobGuid);
+ if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof (UINT64)) {
+DEBUG ((EFI_D_ERROR, "%a: Failed to get Fdt Hob\n", __FUNCTION__));
+return EFI_NOT_FOUND;
+ }
+ DeviceTreeBase = (VOID *)(UINTN)*(UINT64 *)GET_GUID_HOB_DATA (Hob);
+
+ if (fdt_check_header (DeviceTreeBase) != 0) {
+DEBUG ((EFI_D_ERROR, "%a: No DTB found @ 0x%p\n", __FUNCTION__,
DeviceTreeBase));
+return EFI_NOT_FOUND;
+ }
+
+ Node = fdt_path_offset(DeviceTreeBase, "/chosen/modules");
I am not sure if we want to mandate the modules to live in "/chosen".
Would it be possible to look by compatible instead?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Commit moratorium for branching 4.7
Ian Jackson writes ("Commit moratorium for branching 4.7"):
> At Wei's request, I am starting to branch the tree, so that
> xen-unstable can diverge from the *-4.7 preparation branches.
>
> Please don't commit anything until I'm done, which will be later
> today.
I have now finished this branching process. Please let me know of any
anomalies. I have applied the patch below to xen.git#staging, to
(from a technical point of view) open Xen 4.8.
I'm not sure we have made a community decision about the terms under
which patches may be committed to the newly-open 4.8 (and who is
responsible for porting bug fixes from 4.7 to 4.8 or vice versa).
Perhaps I missed the email. I don't think the stable tree maintainers
want to take over 4.7 yet. So until that is settled, probably nothing
substantial should be committed to 4.8.
Commits for 4.7 should now go to xen.git#staging-4.7, on the same
terms as before. (Ie, with Wei's approval.)
The branching process did not involve pushing any change to any of the
4.7 git branches.
Ian.
From 936a7a5483fbdd4ae3d813beff8921e902f43a46 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Tue, 7 Jun 2016 14:49:31 +0100
Subject: [PATCH] Open Xen 4.8-unstable
* Change version number in README and xen/Makefile to `4.8-unstable'.
* Set `debug ?= y'.
* Set QEMU_UPSTREAM_REVISION to track qemu-xen.git `master'.
Signed-off-by: Ian Jackson
CC: Wei Liu
---
Config.mk|4 ++--
README | 12 ++--
xen/Makefile |4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Config.mk b/Config.mk
index bc5c456..e083727 100644
--- a/Config.mk
+++ b/Config.mk
@@ -17,7 +17,7 @@ or = $(if $(strip $(1)),$(1),$(if $(strip
$(2)),$(2),$(if $(strip $(3)),$(
-include $(XEN_ROOT)/.config
# A debug build of Xen and tools?
-debug ?= n
+debug ?= y
debug_symbols ?= $(debug)
# Test coverage support
@@ -272,7 +272,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
endif
OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
-QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc5
+QEMU_UPSTREAM_REVISION ?= master
MINIOS_UPSTREAM_REVISION ?= 1a3ee6eeca136525aa2e6917ae500e7cf731c09d
# Fri May 13 15:21:10 2016 +0100
# lib/sys.c: enclose file_types in define guards
diff --git a/README b/README
index d3f432a..e1ac04a 100644
--- a/README
+++ b/README
@@ -1,10 +1,10 @@
#
-__ ___ _ _
-\ \/ /___ _ __ | || | |___ |_ __ ___
- \ // _ \ '_ \ | || |_ / /| '__/ __|
- / \ __/ | | | |__ _| / /_| | | (__
-/_/\_\___|_| |_||_|(_)_/ |_| \___|
-
+__ ___ ______ _
+\ \/ /___ _ __ | || | ( _ ) _ _ _ __ ___| |_ __ _| |__ | | ___
+ \ // _ \ '_ \ | || |_ / _ \ _| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
+ / \ __/ | | | |__ _| (_) |_| |_| | | | \__ \ || (_| | |_) | | __/
+/_/\_\___|_| |_||_|(_)___/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
+
#
http://www.xen.org/
diff --git a/xen/Makefile b/xen/Makefile
index b59f95d..ee8ce8e 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -1,8 +1,8 @@
# This is the correct place to edit the build version.
# All other places this is stored (eg. compile.h) should be autogenerated.
export XEN_VERSION = 4
-export XEN_SUBVERSION= 7
-export XEN_EXTRAVERSION ?= .0-rc$(XEN_VENDORVERSION)
+export XEN_SUBVERSION= 8
+export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
export XEN_FULLVERSION = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
-include xen-version
--
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 0/2] Test booting hvm guest with empty cdrom drive
Wei Liu writes ("[PATCH OSSTEST v2 0/2] Test booting hvm guest with empty cdrom
drive"):
> This can only go in after the bug is fixed and possibly backported to all the
> trees we care about. It won't pass osstest self pushgate otherwise.
I pushed these but they broke, but only with XSM. See, for example:
From: osstest service owner
To:
Subject: [osstest test] 95322: regressions - FAIL
Date: Mon, 6 Jun 2016 19:29:51 +
flight 95322 osstest real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95322/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install
fail REGR. vs. 93413
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install
fail REGR. vs. 93413
I haven't had a chance to look at why, yet. For now, I have dropped
these patches from the osstest push gate.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 2/3] drivers/pl011: Use combination of UARTRIS and UARTMSC instead of UARTMIS
Hello Shanker,
On 06/06/16 23:58, Shanker Donthineni wrote:
The Masked interrupt status register (UARTMIS) is not described in ARM
SBSA 2.x document. Anding of two registers UARTMSC and UARTRIS values
gives the same information as register UARTMIS.
UARTRIS, UARTMSC and UARTMIS definitions are found in PrimeCell UART
PL011 (Revision: r1p4).
- 3.3.10 Interrupt mask set/clear register, UARTIMSC
- 3.3.11 Raw interrupt status register, UARTRIS
- 3.3.12 Masked interrupt status register, UARTMIS
This change is necessary for driver to be SBSA compliant v2.x without
affecting the current driver functionality.
Signed-off-by: Shanker Donthineni
---
Fixed typo in commit text.
xen/drivers/char/pl011.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 6a3c21b..755a965 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -57,7 +57,10 @@ static void pl011_interrupt(int irq, void *data, struct
cpu_user_regs *regs)
{
struct serial_port *port = data;
struct pl011 *uart = port->uart;
-unsigned int status = pl011_read(uart, MIS);
+unsigned int status;
+
+/* UARTMIS is not documented in SBSA v2.x, so using UARTRIS/UARTIMSC */
+status = pl011_read(uart, RIS) & pl011_read(uart, IMSC);
Please use an helper here to avoid code duplication and have the comment
in both place.
if ( status )
{
@@ -76,7 +79,7 @@ static void pl011_interrupt(int irq, void *data, struct
cpu_user_regs *regs)
if ( status & (TXI) )
serial_tx_interrupt(port, regs);
-status = pl011_read(uart, MIS);
+status = pl011_read(uart, RIS) & pl011_read(uart, IMSC);
} while (status != 0);
}
}
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 1/3] drivers/pl011: Don't configure baudrate
Hello Shanker, On 06/06/16 23:58, Shanker Donthineni wrote: The default baud and clock_hz configuration parameters are hardcoded (commit 60ff980995008caf) for Versatile Express. Other platforms, these default values may not be valid and might cause problems by programming registers IBRD and FBRD incorrectly. So, removing driver logic that sets the baudrate to fix the problem. The boot firmware is responsible for setting the correct baudrate. It might be worth to say that the behavior is unchanged because the driver was already relying on the boot firmware. Other than that: Reviewed-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Build problems with xen 4.7
On Tue, Jun 07, M A Young wrote: > That may not be needed in general. It is something I added for Fedora as I > am cross-compiling the hypervisor as x86_64 to put in the i686 package > because ix86 hypervisors are no longer supported. What exactly are you doing anyway? If xen/ is supposed to be a 64bit binary and tools/ should be 32bit then configure --disable-xen should be used. 'make' will do the 32bit build, and 'make xen' the 64bit build. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
On 06/07/2016 02:17 AM, Jan Beulich wrote:
On 06.06.16 at 18:59, wrote:
>> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>> On 06.04.16 at 03:25, wrote:
+#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
+#define ACPI_PHYSICAL_ADDRESS 0x000EA020
+
+/* Initial allocation for ACPI tables */
+#define NUM_ACPI_PAGES 16
>>> With which other definitions do these three need to remain in sync?
>> NUM_ACPI_PAGES is private to this file.
>>
>> ACPI_PHYSICAL_ADDRESS (RSDP pointer) needs to be between 0xe and
>> 0xf, I picked this number because that's where most systems that I have
>> appear to have it. (And by "most" I mean the two that I checked ;-))
> With there not being a BIOS, I can see this being pretty arbitrary.
> Yet in that case I'm not convinced of this getting put at a random
> address in the middle.
I can put it in the beginning, at 0xe.
> Plus I'm not sure I see the connection to the
> reservations done in the E820 map the guest gets to see.
I thought ACPI data is supposed to live in reserved areas (ACPI data,
actually)?
>
>> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka
>> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need
>> SystemMemory so it can be anywhere (and e820 should presumably be aware of
>> this, which it is not right now)
> So you say there's no connection to the end of hvmloader's window
> for PCI MMIO assignments (an equivalent of which is going to be
> needed for PVHv2)?
I haven't thought about this but then we don't have MMIO hole now. I can
try finding available memory chunk in guest's memory under 4G.
>
+static int init_acpi_config(struct xc_dom_image *dom,
+struct acpi_config *config)
+{
+xc_interface *xch = dom->xch;
+uint32_t domid = dom->guest_domid;
+xc_dominfo_t info;
+int i, rc;
+
+memset(config, 0, sizeof(*config));
+
+config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
+config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
>>> What good does an empty DSDT do? (Perhaps this question is a
>>> result of there not being any description of this change.)
>> DSDT is required to be present by the spec. And ACPICA gets upset if it
>> doesn't see it.
> But my point (also mentioned further down in the original reply) was
> that there's no need for anything if acpi=0.
Right, but the whole routine will not be called if that's the case (in v1).
> But note that as soon as
> you report processors in MADT, the combined set of tables holding
> AML code can't be empty anymore: Processors need to be
> declared using Processor() (legacy) or Device(). Maybe we don't
> need as much as an ordinary HVM guest, but nothing seems too little.
I will add Processor.
>
--- a/xen/common/libacpi/build.c
+++ b/xen/common/libacpi/build.c
@@ -480,7 +480,7 @@ static int new_vm_gid(struct acpi_config *config)
return 1;
}
-void acpi_build_tables(struct acpi_config *config, unsigned int physical)
+void acpi_build_tables(struct acpi_config *config, unsigned long physical)
>>> I'm having some difficulty seeing how this change belongs here.
>> acpi_build_tables() is called with virtual (i.e. 64-bit) address from libxc.
> Oh - so the parameter name is then wrong?
Yes, it should have a more appropriate name. Like rsdp or something like
that.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
