Re: [Xen-devel] Xen on Arm Arndale Exynos5250
On Thu, 2015-11-05 at 12:59 -0600, ed sandberg wrote: > > My initial thought was that I needed to add a getty process on COM3, so > that when I switched to Dom0 mode I could login. This page seems to > agree with me: > > http://wiki.xenproject.org/wiki/Xen_Serial_Console > > I tried to do so by creating a ttyS2.conf file under /etc/init/ that > read as follows: > > start on stopped rc RUNLEVEL=[2345] > stop on runlevel [!2345] > > respawn > exec /sbin/getty -8 115200 ttyS2 > > with that in place I was still not prompted to login but it had an > effect because the serial connection would become unresponsive after a > few minutes. IIRC Linux's name for the console serial device on Arndale is ttySAC2, so that is what you would want when booting natively (unless Linaro have done some pretty extreme patching, which I wouldn't expect. I've only used mainline on this platform). If you are running as dom0 under Xen you want to have a getty on "/dev/hvc0", the Xen PV console device, since the real UART will be owned by Xen (due to the "dtuart=/serial@12C2" which you will be passing on Xen's command line). I don't think any of the Arndale devices have multiple serial ports exposed, but if they did then you could use separate ones for Xen's and dom0's console, but the Linux name for dom0 would still be ttySAC not ttyS. When you created /etc/init/ttyS2.conf were there other similar files around in that directory? I ask because that sounds like an upstart path and I'm unsure if Saucy still uses upstart. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ovmf fail to compile
> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: Wednesday, November 4, 2015 6:19 PM > To: Hao, Xudong > Cc: Wei Liu ; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] ovmf fail to compile > > On Wed, Nov 04, 2015 at 08:27:56AM +, Hao, Xudong wrote: > > "git clean -fdx" doesn't change the error result with gcc 4.4.7. Gcc > > version is > "gcc-4.4.?" in Debian Jessie of yours? > > > > Debian Jessie's gcc-4.4 has the same version 4.4.7. > > As the other sub-thread suggests, can you try passing more f's to git? > After more f's (git clean -), still met same compile issue. > A somewhat related question, are you only interested in xen-unstable branch? > Have you tried latest OVMF from upstream? If that builds for you I can easily > send another patch to update Config.mk again. > Checked the upstream OVMF (git://git.code.sf.net/p/tianocore/edk2), the compile issue persist with gcc 4.4.7. Maybe I can raise it to EDKII community. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [chg req] console: provide a way to send escape char
I would like to request that there be a way in the xen console
to send the escape char. The problem I faced was that I did:
xl console
domU> telnet
...
At some point, I realised that I wanted to send Ctrl-], which is
the standard telnet escape char to the telnet command. But, of
course, the xen console ate it and exited. A Google search and
asking a developer that was hanging out in a private chat where I
often hangout didn't produce any answers. So, then I looked at
tools/console/client/main.c in Xen 4.5.1, which is the latest that
I had at hand, along with master in your gitweb, I found the
following code:
212 if (FD_ISSET(STDIN_FILENO, &fds)) {
213 ssize_t len;
214 char msg[60];
215
216 len = read(STDIN_FILENO, msg, sizeof(msg));
217 if (len == 1 && msg[0] == ESCAPE_CHARACTER) {
218 return 0;
219 }
Thus it would appear that there is currently no way to send the
escape char to the domU. I would provide a patch, but I'm not sure
what would be the best way to make the change.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-jessie test] 38254: tolerable all pass
flight 38254 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38254/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail never pass test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail never pass baseline version: flight 38226 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub pass test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub pass test-amd64-amd64-i386-jessie-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ovmf fail to compile
On Fri, Nov 06, 2015 at 08:53:27AM +, Hao, Xudong wrote: > > -Original Message- > > From: Wei Liu [mailto:wei.l...@citrix.com] > > Sent: Wednesday, November 4, 2015 6:19 PM > > To: Hao, Xudong > > Cc: Wei Liu ; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] ovmf fail to compile > > > > On Wed, Nov 04, 2015 at 08:27:56AM +, Hao, Xudong wrote: > > > "git clean -fdx" doesn't change the error result with gcc 4.4.7. Gcc > > > version is > > "gcc-4.4.?" in Debian Jessie of yours? > > > > > > > Debian Jessie's gcc-4.4 has the same version 4.4.7. > > > > As the other sub-thread suggests, can you try passing more f's to git? > > > > After more f's (git clean -), still met same compile issue. > > > A somewhat related question, are you only interested in xen-unstable branch? > > Have you tried latest OVMF from upstream? If that builds for you I can > > easily > > send another patch to update Config.mk again. > > > > Checked the upstream OVMF (git://git.code.sf.net/p/tianocore/edk2), the > compile issue persist with gcc 4.4.7. Maybe I can raise it to EDKII community. Right. Looks like this is an issue in upstream. Thanks for your investigation. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [chg req] console: provide a way to send escape char
On Fri, Nov 06, 2015 at 02:31:22AM -0800, John Nemeth wrote:
> I would like to request that there be a way in the xen console
> to send the escape char. The problem I faced was that I did:
>
> xl console
> domU> telnet
As a workaround, you can try
telnet -e escapechar
?
> ...
>
> At some point, I realised that I wanted to send Ctrl-], which is
> the standard telnet escape char to the telnet command. But, of
> course, the xen console ate it and exited. A Google search and
> asking a developer that was hanging out in a private chat where I
> often hangout didn't produce any answers. So, then I looked at
> tools/console/client/main.c in Xen 4.5.1, which is the latest that
> I had at hand, along with master in your gitweb, I found the
> following code:
>
> 212 if (FD_ISSET(STDIN_FILENO, &fds)) {
> 213 ssize_t len;
> 214 char msg[60];
> 215
> 216 len = read(STDIN_FILENO, msg, sizeof(msg));
> 217 if (len == 1 && msg[0] == ESCAPE_CHARACTER) {
> 218 return 0;
> 219 }
>
> Thus it would appear that there is currently no way to send the
> escape char to the domU. I would provide a patch, but I'm not sure
> what would be the best way to make the change.
>
Maybe we can do the same thing as telnet to provide an option to specify
escape character.
Wei.
> ___
> 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] [chg req] console: provide a way to send escape char
On Nov 6, 10:37am, Wei Liu wrote:
} On Fri, Nov 06, 2015 at 02:31:22AM -0800, John Nemeth wrote:
} > I would like to request that there be a way in the xen console
} > to send the escape char. The problem I faced was that I did:
} >
} > xl console
} > domU> telnet
}
} As a workaround, you can try
}
}telnet -e escapechar
}
} ?
I could if I thought about it ahead of time. The end of the
chain was a serial connection to the console port of a Cisco switch.
Since it thought I was on a direct serial link, it had no way to
drop the connection. The device prior in the chain was an old
Cisco router being used as a serial concentrator to act as console
for a bunch of other devices. I was also unable to send the escape
character (ctrl-^) for it (on some systems, it is a different key
combination which I don't recall).
That left me kinda stuck. Luckily for this situation, I had
a different method of directly logging into the serial concentrator
and could forcibly drop the connection.
} > ...
} >
} > At some point, I realised that I wanted to send Ctrl-], which is
} > the standard telnet escape char to the telnet command. But, of
} > course, the xen console ate it and exited. A Google search and
} > asking a developer that was hanging out in a private chat where I
} > often hangout didn't produce any answers. So, then I looked at
} > tools/console/client/main.c in Xen 4.5.1, which is the latest that
} > I had at hand, along with master in your gitweb, I found the
} > following code:
} >
} > 212 if (FD_ISSET(STDIN_FILENO, &fds)) {
} > 213 ssize_t len;
} > 214 char msg[60];
} > 215
} > 216 len = read(STDIN_FILENO, msg, sizeof(msg));
} > 217 if (len == 1 && msg[0] == ESCAPE_CHARACTER) {
} > 218 return 0;
} > 219 }
} >
} > Thus it would appear that there is currently no way to send the
} > escape char to the domU. I would provide a patch, but I'm not sure
} > what would be the best way to make the change.
}
} Maybe we can do the same thing as telnet to provide an option to specify
} escape character.
This would be useful if one thinks about it in advance.
However, it may still be useful for other situations.
}-- End of excerpt from Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 6
The document looks good to me. I would appreciate if the linux guys
could give a look at the last three paragraphs under section 5.
On Thu, 5 Nov 2015, Shannon Zhao wrote:
> This document is going to explain the design details of Xen booting with
> ACPI on ARM. Any comments are welcome.
>
> Changes v5->v6:
> * add a new node "uefi" under /hypervisor to pass UEFI informations to
> Dom0 instead of the nodes under /chosen.
> * change creation of MADT table, get the information from
> domain->arch.vgic struct
> * Reuse grant table region which will not be used by Dom0 when booting
> through ACPI to store the new created ACPI tables.
>
> Changes v4->v5:
> * change the description of section 4 to make it more generic
> * place EFI and ACPI tables at non-RAM space of Dom0
>
> Changes v3->v4:
> * add explanation for minimal DT and the properties
> * drop "linux," prefix of the properties
> * add explanation for the event channel flag
> * create RSDP table since the "xsdt_physical_address" is changed
> * since it uses hypervisor_id introduced by ACPI 6.0 to notify Dom0 the
> hypervisor ID, so it needs to limit minimum supported ACPI version for
> Xen on ARM to 6.0.
>
> Changes v2->v3:
> * remove the two HVM_PARAMs for grant table and let linux kernel use
> xlated_setup_gnttab_pages() to setup grant table.
> * don't modify GTDT table
> * add definition of event-channel interrupt flag
> * state that route all Xen unused interrupt to Dom0
> * state that reusing existing PCI bus_notifier for PCI devices MMIO
> * mapping
>
> To Xen itself booting with ACPI, this is similar to Linux kernel except
> that Xen doesn't parse DSDT table. So I'll skip this part and focus on
> how Xen prepares ACPI tables for Dom0 and how Xen passes them to Dom0.
>
> 1. Create minimal DT to pass required informations to Dom0
> --
> When booting in UEFI mode on ARM64, it needs to pass some UEFI
> informations to Dom0. The necessary informations is the address of EFI
> System table and EFI Memory Descriptor table, the size of EFI Memory
> Descriptor table, the size of EFI Memory Descriptor and the version of
> EFI Memory Descriptor. Here it passes these informations through the
> "uefi" node under hypervisor of this minimal DT. Dom0 should parse this
> DT to get Xen UEFI informations like the way Linux kernel getting normal
> UEFI informations. Also, it should check if the DT contains only the
> /hypervisor and /chosen nodes to know whether it boots with DT or ACPI.
>
> In addition, Dom0 should parse DT to know whether it runs on Xen
> hypervisor, then it should execute a Xen UEFI specific routine to
> initialize UEFI.
>
> An example of the minimal DT:
> / {
> #address-cells = <2>;
> #size-cells = <2>;
> hypervisor {
> compatible = "xen,xen-4.3", "xen,xen";
> reg = <0 0xb000 0 0x2>; /* Only need for booting
> without ACPI */
> interrupts = <1 15 0xf08>; /* Only need for booting without ACPI */
> uefi {
> xen,uefi-system-table = <0x>;
> xen,uefi-mmap-start = <0x>;
> xen,uefi-mmap-size = <0x>;
> xen,uefi-mmap-desc-size = <0x>;
> xen,uefi-mmap-desc-ver = <0x>;
> };
> };
>
> chosen {
> bootargs = "kernel=Image console=hvc0 earlycon=pl011,0x1c09
> root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force";
> linux,initrd-start = <0x>;
> linux,initrd-end = <0x>;
> };
> };
>
> For details loook at(this will be updated by a patch of Linux kernel)
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/arm/xen.txt
>
> 2. Copy and change some EFI and ACPI tables
> ---
> a) Create EFI_SYSTEM_TABLE table
> Create a new EFI System table. Copy the table header from host original
> EFI System table. Change the value of HeaderSize, CRC32 and Revision
> fields in this EFI System table header. Assign new values for
> FirmwareVendor and FirmwareRevision fields of EFI System table. Create
> one ConfigurationTable and assign the value of VendorGuid field to
> ACPI_20_TABLE_GUID, the value of VendorTable field to the address of
> ACPI RSDP table. This EFI System Table will be passed to Dom0 through
> the property "uefi-system-table" in the above minimal DT. So Dom0 could
> get ACPI root table address through the ConfigurationTable.
>
> b) Create EFI_MEMORY_DESCRIPTOR table
> It needs to notify Dom0 where are the RAM regions. Add memory start and
> size information of Dom0 in this table. It's passed to Dom0 through the
> properties "uefi-mmap-start", "uefi-mmap-size", "uefi-mmap-desc-size"
> and "uefi-mmap-desc-ver" of the minimal DT. Then Dom0 will get the
> memory information through this EFI table.
>
> c) Create FADT table
> Firstly copy the contents of host FADT table to the new created FADT
> table. Then c
Re: [Xen-devel] [PATCH v12 3/3] iommu: add rmrr Xen command line option for extra rmrrs
>>> On 06.11.15 at 05:22, wrote:
> On Wed, Oct 28, 2015 at 10:05:31AM -0600, Jan Beulich wrote:
>> >>> On 27.10.15 at 21:36, wrote:
>> > +static void __init add_extra_rmrr(void)
>> > +{
>> > +struct acpi_rmrr_unit *acpi_rmrr;
>> > +struct acpi_rmrr_unit *rmrru;
>> > +unsigned int dev, seg, i;
>> > +unsigned long pfn;
>> > +bool_t overlap;
>> > +
>> > +for ( i = 0; i < nr_rmrr; i++ )
>> > +{
>> > +if ( extra_rmrr_units[i].base_pfn > extra_rmrr_units[i].end_pfn )
>> > +{
>> > +printk(XENLOG_ERR VTDPREFIX
>> > + "Invalid RMRR Range "ERMRRU_FMT"\n",
>> > + ERMRRU_ARG(extra_rmrr_units[i]));
>> > +continue;
>> > +}
>> > +
>> > +if ( extra_rmrr_units[i].end_pfn - extra_rmrr_units[i].base_pfn >=
>> > + MAX_EXTRA_RMRR_PAGES )
>> > +{
>> > +printk(XENLOG_ERR VTDPREFIX
>> > + "RMRR range "ERMRRU_FMT" exceeds
>> > "__stringify(MAX_EXTRA_RMRR_PAGES)" pages\n",
>> > + ERMRRU_ARG(extra_rmrr_units[i]));
>> > +continue;
>> > +}
>> > +
>> > +overlap = 0;
>> > +list_for_each_entry(rmrru, &acpi_rmrr_units, list)
>> > +{
>> > +if ( pfn_to_paddr(extra_rmrr_units[i].base_pfn) <
>> > rmrru->end_address &&
>> > + rmrru->base_address <
>> > pfn_to_paddr(extra_rmrr_units[i].end_pfn + 1) )
>>
>> Aren't both ranges inclusive? I.e. shouldn't the first one be <= (and
>> the second one could be <= too when dropping the +1), matching
>> the check acpi_parse_one_rmrr() does?
>
> The end_address is not inclusive, while the start_address is.
> These to from rmrr_identity_mapping()
> ...
> ASSERT(rmrr->base_address < rmrr->end_address);
>
These are byte-granular addresses.
> and:
> ...
> while ( base_pfn < end_pfn )
> {
> int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
>
>
> if ( err )
>
> return err;
>
> base_pfn++;
>
> }
> ...
>
> I think this condition should not be a problem. But yes, its not uniform
> with acpi_parse_one_rmrr.
Did you actually pay attention to how end_pfn gets calculated?
> I guess I should send another version then?
Yes of course.
>> > +}
>> > +if ( seg != PCI_SEG(extra_rmrr_units[i].sbdf[0]) )
>> > +{
>> > +printk(XENLOG_ERR VTDPREFIX
>> > + "Segments are not equal for RMRR range "ERMRRU_FMT"\n",
>> > + ERMRRU_ARG(extra_rmrr_units[i]));
>> > +scope_devices_free(&acpi_rmrr->scope);
>> > +xfree(acpi_rmrr);
>> > +continue;
>> > +}
>> > +
>> > +acpi_rmrr->segment = seg;
>> > +acpi_rmrr->base_address =
> pfn_to_paddr(extra_rmrr_units[i].base_pfn);
>> > +acpi_rmrr->end_address = pfn_to_paddr(extra_rmrr_units[i].end_pfn
>> > +
> 1);
>>
>> And this seems wrong too, unless I'm mistaken with the inclusive-ness.
>>
> The end_address is exclusive, see above.
No - see above.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 1/5] xen: move xen_setup_runstate_info and get_runstate_snapshot to drivers/xen/time.c
On Thu, 5 Nov 2015, Mark Rutland wrote:
> Hi,
>
> > +static u64 get64(const u64 *p)
> > +{
> > + u64 ret;
> > +
> > + if (BITS_PER_LONG < 64) {
> > + u32 *p32 = (u32 *)p;
> > + u32 h, l;
> > +
> > + /*
> > +* Read high then low, and then make sure high is
> > +* still the same; this will only loop if low wraps
> > +* and carries into high.
> > +* XXX some clean way to make this endian-proof?
> > +*/
> > + do {
> > + h = p32[1];
> > + barrier();
> > + l = p32[0];
> > + barrier();
> > + } while (p32[1] != h);
>
> I realise this is simply a move of existing code, but it may be better
> to instead have:
>
> do {
> h = READ_ONCE(p32[1]);
> l = READ_ONCE(p32[0]);
> } while (READ_ONCE(p32[1] != h);
>
> Which ensures that each load is a single access (though it almost
> certainly would be anyway), and prevents the compiler from having to
> reload any other memory locations (which the current barrier() usage
> forces).
I am happy to make these changes, however for code clarity and review
simplicity I'll keep them on a separate patch (I like code movement to
remain code movement). I can squash the two patches together when
committing, if necessary.
> > +
> > + ret = (((u64)h) << 32) | l;
> > + } else
> > + ret = *p;
>
> Likewise, this would be better as READ_ONCE(*p), to force a single
> access.
>
> > +
> > + return ret;
> > +}
>
> > + do {
> > + state_time = get64(&state->state_entry_time);
> > + barrier();
> > + *res = *state;
> > + barrier();
>
> You can also have:
>
> *res = READ_ONCE(*state);
>
> That will which will handle the barriers implicitly.
>
> Thanks,
> Mark.
>
> > + } while (get64(&state->state_entry_time) != state_time);
> > +}
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [win-pv-devel] 2016 Xen Dev Summit Location (input needed before next Thu)
> -Original Message- > From: win-pv-devel-boun...@lists.xenproject.org [mailto:win-pv-devel- > boun...@lists.xenproject.org] On Behalf Of Lars Kurth > Sent: 05 November 2015 18:31 > To: Xen-devel; mirageos-de...@xenproject.org; xen- > a...@lists.xenproject.org; win-pv-de...@lists.xenproject.org > Subject: [win-pv-devel] 2016 Xen Dev Summit Location (input needed before > next Thu) > > Hi all, > > I was just informed that it is not going to be possible to hold the Developer > Summit alongside LinuxCon in Berlin, unless we make some hard choices. I > had originally had booked the space and all looked fine when it was originally > arranged several months ago. Seems that the LinuxCon organisers tripped > over a German holiday and had not accounted for it. I would like to get your > input before the next board meeting in 10 days, such that I have community > input for the meeting and I can make a swift decision at the meeting. > > We have the following options > * Hold it on Monday Oct 3 - to Tue Oct 4 : the problem is that Oct 3 is a > public > holiday in Germany, which would affect German participants > * Do a 1 day event only on Oct 4 : I don't think this is practicable > * Hold the event alongside LinuxCon in Toronto in August, but then we'd > have a Dev Summit in the US for 3 years in a row. I think some Canadians might get offended at that! ;-) s/US/North America > On the plus side, it will be > Linux' 25th birthday > > Other options, such as holding the event on its own will be too expensive. > Please let me know your opinions. I think Toronto would be fine. Paul > > Best Regards > Lars > > > From: Angela Brown > > Subject: Xen Summit 2016 > > Date: 5 November 2015 17:32:11 GMT > > To: Lars Kurth > > > > Hi Lars, > > > > Sorry for the delay in getting back to you as we had to get a few things > sorted. > > > > First the bad news. It turns out that Monday, October 3, 2016 is German > Unity Day and we've decided it will not be a good idea to hold LinuxCon on > this day. So we are moving LinuxCon/ContainerCon to Tuesday, Wednesday, > Thursday of that week and ELC-E will be Thursday & Friday as scheduled. This > means that we have absolutely no additional space on Thursday. In addition, > the space we do have in terms of larger rooms on Tuesday and Wednesday is > extremely limited. We went through all the space yesterday, and we don't > have any extra rooms that fit over 50ppl available on Tuesday & Wednesday. > Thus, holding Xen Summit overlapping in Berlin at the same venue isn't going > to work. The only real option for larger rooms in Berlin would be on Monday > (but not on Tuesday, and again this is a holiday). > > > > We can co-locate in Toronto in August but only on the two days after > LinuxCon/ContainerCon - Thursday and Friday (but we can do your board > meetings on Wednesday). Please let me know if you want me to go ahead > and put together a proposal for this or if you have something else in mind. > > > > Thanks and sorry! > > > > Angela > > ___ > win-pv-devel mailing list > win-pv-de...@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 2016 Xen Dev Summit Location (input needed before next Thu)
On Thu, 5 Nov 2015, Lars Kurth wrote: > Hi all, > > I was just informed that it is not going to be possible to hold the Developer > Summit alongside LinuxCon in Berlin, unless we make some hard choices. I had > originally had booked the space and all looked fine when it was originally > arranged several months ago. Seems that the LinuxCon organisers tripped over > a German holiday and had not accounted for it. I would like to get your input > before the next board meeting in 10 days, such that I have community input > for the meeting and I can make a swift decision at the meeting. > > We have the following options > * Hold it on Monday Oct 3 - to Tue Oct 4 : the problem is that Oct 3 is a > public holiday in Germany, which would affect German participants > * Do a 1 day event only on Oct 4 : I don't think this is practicable > * Hold the event alongside LinuxCon in Toronto in August, but then we'd have > a Dev Summit in the US for 3 years in a row. On the plus side, it will be > Linux' 25th birthday I really enjoyed the celebrations for Linux' 20th birthday in Vancouver, so I vote for Toronto :-) > Other options, such as holding the event on its own will be too expensive. > Please let me know your opinions. > > Best Regards > Lars > > > From: Angela Brown > > Subject: Xen Summit 2016 > > Date: 5 November 2015 17:32:11 GMT > > To: Lars Kurth > > > > Hi Lars, > > > > Sorry for the delay in getting back to you as we had to get a few things > > sorted. > > > > First the bad news. It turns out that Monday, October 3, 2016 is German > > Unity Day and we've decided it will not be a good idea to hold LinuxCon on > > this day. So we are moving LinuxCon/ContainerCon to Tuesday, Wednesday, > > Thursday of that week and ELC-E will be Thursday & Friday as scheduled. > > This means that we have absolutely no additional space on Thursday. In > > addition, the space we do have in terms of larger rooms on Tuesday and > > Wednesday is extremely limited. We went through all the space yesterday, > > and we don't have any extra rooms that fit over 50ppl available on Tuesday > > & Wednesday. Thus, holding Xen Summit overlapping in Berlin at the same > > venue isn't going to work. The only real option for larger rooms in Berlin > > would be on Monday (but not on Tuesday, and again this is a holiday). > > > > We can co-locate in Toronto in August but only on the two days after > > LinuxCon/ContainerCon - Thursday and Friday (but we can do your board > > meetings on Wednesday). Please let me know if you want me to go ahead and > > put together a proposal for this or if you have something else in mind. > > > > Thanks and sorry! > > > > Angela > > ___ > 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 v2 1/2] xen/serial: Move any OMAP specific things to OMAP UART driver
>>> On 05.11.15 at 18:53, wrote: > The 8250-uart.h contains extra serial register definitions > for the internal UARTs in TI OMAP SoCs which are used in > OMAP UART driver only. > In order to clean up code move these definitions to omap-uart.c. > Also rename some definitions to follow to the UART_OMAP* prefix. > > Signed-off-by: Oleksandr Tyshchenko > CC: Ian Campbell > CC: Julien Grall > CC: Stefano Stabellini > Cc: Jan Beulich The Cc list of the mail disagrees with the list above, but nevertheless Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 2016 Xen Dev Summit Location (input needed before next Thu)
On Thu, 5 Nov 2015, Lars Kurth wrote: Hi all, I was just informed that it is not going to be possible to hold the Developer Summit alongside LinuxCon in Berlin, unless we make some hard choices. I had originally had booked the space and all looked fine when it was originally arranged several months ago. Seems that the LinuxCon organisers tripped over a German holiday and had not accounted for it. I would like to get your input before the next board meeting in 10 days, such that I have community input for the meeting and I can make a swift decision at the meeting. We have the following options * Hold it on Monday Oct 3 - to Tue Oct 4 : the problem is that Oct 3 is a public holiday in Germany, which would affect German participants * Do a 1 day event only on Oct 4 : I don't think this is practicable * Hold the event alongside LinuxCon in Toronto in August, but then we'd have a Dev Summit in the US for 3 years in a row. On the plus side, it will be Linux' 25th birthday Monday Oct 3 - to Tue Oct 4 in Berlin would be my preference. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 5/5] xen/arm: account for stolen ticks
On 06/11/15 11:39, Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Mark Rutland wrote:
>>> static void xen_percpu_init(void)
>>> {
>>> struct vcpu_register_vcpu_info info;
>>> @@ -104,6 +120,8 @@ static void xen_percpu_init(void)
>>> BUG_ON(err);
>>> per_cpu(xen_vcpu, cpu) = vcpup;
>>>
>>> + xen_setup_runstate_info(cpu);
>>
>> Does the runstate memory area get unregsitered when a kernel tears
>> things down, or is kexec somehow inhibited for xen guests?
>>
>> i couldn't spot either happening, but I may have missed it.
>
> I don't think that the runstate memory area needs to be unregistered for
> kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly
> and David.
There's a whole pile of other state needing to be reset for kexec (event
channels and grant tables for example). The guest needs to soft reset
itself (available in Xen 4.6) before kexec'ing another kernel.
This soft reset would also including cleaning up this shared memory region.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 5/5] xen/arm: account for stolen ticks
On Thu, 5 Nov 2015, Mark Rutland wrote:
> > static void xen_percpu_init(void)
> > {
> > struct vcpu_register_vcpu_info info;
> > @@ -104,6 +120,8 @@ static void xen_percpu_init(void)
> > BUG_ON(err);
> > per_cpu(xen_vcpu, cpu) = vcpup;
> >
> > + xen_setup_runstate_info(cpu);
>
> Does the runstate memory area get unregsitered when a kernel tears
> things down, or is kexec somehow inhibited for xen guests?
>
> i couldn't spot either happening, but I may have missed it.
I don't think that the runstate memory area needs to be unregistered for
kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly
and David.
> > +
> > after_register_vcpu_info:
> > enable_percpu_irq(xen_events_irq, 0);
> > put_cpu();
> > @@ -271,6 +289,9 @@ static int __init xen_guest_init(void)
> >
> > register_cpu_notifier(&xen_cpu_notifier);
> >
> > + pv_time_ops.steal_clock = xen_stolen_accounting;
> > + static_key_slow_inc(¶virt_steal_enabled);
> > +
> > return 0;
> > }
> > early_initcall(xen_guest_init);
> > --
> > 1.7.10.4
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] 2016 Xen Dev Summit Location (input needed before next Thu)
On 05/11/15 18:31, Lars Kurth wrote: > Hi all, > > We have the following options * Hold it on Monday Oct 3 - to Tue Oct > 4 : the problem is that Oct 3 is a public holiday in Germany, which > would affect German participants The email from Angela below says there's no rooms available on the Tues "we don't have any extra rooms that fit over 50ppl available on Tuesday & Wednesday" Does this not exclude XenSummit on the Mon-Tue? > * Do a 1 day event only on Oct 4 : I don't think this is practicable See above re rooms on Tuesday. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 5/5] xen/arm: account for stolen ticks
On Fri, Nov 06, 2015 at 11:41:49AM +, David Vrabel wrote:
> On 06/11/15 11:39, Stefano Stabellini wrote:
> > On Thu, 5 Nov 2015, Mark Rutland wrote:
> >>> static void xen_percpu_init(void)
> >>> {
> >>> struct vcpu_register_vcpu_info info;
> >>> @@ -104,6 +120,8 @@ static void xen_percpu_init(void)
> >>> BUG_ON(err);
> >>> per_cpu(xen_vcpu, cpu) = vcpup;
> >>>
> >>> + xen_setup_runstate_info(cpu);
> >>
> >> Does the runstate memory area get unregsitered when a kernel tears
> >> things down, or is kexec somehow inhibited for xen guests?
> >>
> >> i couldn't spot either happening, but I may have missed it.
> >
> > I don't think that the runstate memory area needs to be unregistered for
> > kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly
> > and David.
>
> There's a whole pile of other state needing to be reset for kexec (event
> channels and grant tables for example). The guest needs to soft reset
> itself (available in Xen 4.6) before kexec'ing another kernel.
>
> This soft reset would also including cleaning up this shared memory region.
Ok. So we don't currently have the code kernel-side, but it looks like
it would be relatively simple to add (having just spotted [1]), and
everything should be ready on the Xen side.`
Thanks,
Mark.
[1] https://lkml.org/lkml/2015/9/25/152
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 1/5] xen: move xen_setup_runstate_info and get_runstate_snapshot to drivers/xen/time.c
On Fri, Nov 06, 2015 at 11:11:40AM +, Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Mark Rutland wrote:
> > Hi,
> >
> > > +static u64 get64(const u64 *p)
> > > +{
> > > + u64 ret;
> > > +
> > > + if (BITS_PER_LONG < 64) {
> > > + u32 *p32 = (u32 *)p;
> > > + u32 h, l;
> > > +
> > > + /*
> > > + * Read high then low, and then make sure high is
> > > + * still the same; this will only loop if low wraps
> > > + * and carries into high.
> > > + * XXX some clean way to make this endian-proof?
> > > + */
> > > + do {
> > > + h = p32[1];
> > > + barrier();
> > > + l = p32[0];
> > > + barrier();
> > > + } while (p32[1] != h);
> >
> > I realise this is simply a move of existing code, but it may be better
> > to instead have:
> >
> > do {
> > h = READ_ONCE(p32[1]);
> > l = READ_ONCE(p32[0]);
> > } while (READ_ONCE(p32[1] != h);
> >
> > Which ensures that each load is a single access (though it almost
> > certainly would be anyway), and prevents the compiler from having to
> > reload any other memory locations (which the current barrier() usage
> > forces).
>
> I am happy to make these changes, however for code clarity and review
> simplicity I'll keep them on a separate patch (I like code movement to
> remain code movement). I can squash the two patches together when
> committing, if necessary.
Sure, I also prefer to separate code movement from code rework, so that
makes sense to me.
Thanks,
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On Wed, 2015-11-04 at 16:50 +, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the
> macro set_xen_guest_handle_raw"):
> > All quite interesting, but pretty moot with there not being any
> > get_xen_guest_handle() anymore.
>
> If we don't provide a get_xen_guest_handle, a kernel developer will be
> sorely tempted to make one.
>
> If they do and they write it in the obvious way, then the compiler
> could `deduce' that the top part of the uint64_t store was dead, and
> eliminate it.
I realise that "correct use of unions" here is orthogonal to "using gcc
extensions", but trying to achieve the former while avoiding the later
is having a multiplicative effect on the complexity of the resulting
macros, so:...
Realistically any OS which did try and implement this would probably
not try and jump through such hoops in order to do it in pure ANSI-C
but would instead just use whatever extension their compiler provided
to make it easier to write such macros (such as typeof).
Perhaps we should follow the lead of xen/include/public/io/ring.h here
and provide a clear, readable and correct version under #if __GNUC__
(which our own tools build would use) using the extensions and an
alternative ANSI-C only one which might have short comings e.g. in
efficiency, maybe evaluating the argument more than once, etc but not
in correctness.
Realistically IMHO the #else case could be "#error you need to
implement this carefully" but I suspect others will not be comfortable
with that approach.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock
> + delta = arch_timer_read_counter(); /* time since system boot */ > + delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec; The arch counter value is not a number of nanoseconds (unless CNTFRQ reads as 100), so this doesn't look right; the units don't match. Thanks, Mark. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [win-pv-devel] 2016 Xen Dev Summit Location (input needed before next Thu)
> On 6 Nov 2015, at 11:24, Paul Durrant wrote: >> >> We have the following options >> * Hold it on Monday Oct 3 - to Tue Oct 4 : the problem is that Oct 3 is a >> public >> holiday in Germany, which would affect German participants >> * Do a 1 day event only on Oct 4 : I don't think this is practicable >> * Hold the event alongside LinuxCon in Toronto in August, but then we'd >> have a Dev Summit in the US for 3 years in a row. > > I think some Canadians might get offended at that! ;-) > > s/US/North America Apologies to any Canadians: that's of course what I meant. Shouldn't write e-mails late at night after a beer Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 2016 Xen Dev Summit Location (input needed before next Thu)
> On 6 Nov 2015, at 11:44, David Vrabel wrote: > > On 05/11/15 18:31, Lars Kurth wrote: >> Hi all, >> >> We have the following options * Hold it on Monday Oct 3 - to Tue Oct >> 4 : the problem is that Oct 3 is a public holiday in Germany, which >> would affect German participants > > The email from Angela below says there's no rooms available on the Tues > > "we don't have any extra rooms that fit over 50ppl available on > Tuesday & Wednesday" > > Does this not exclude XenSummit on the Mon-Tue? Oh yes, you are correct. Well spotted. Apologies. So we absolutely no easy option but to go for Toronto, unless - We can find two smaller rooms on Tuesday Oct 4th, which I can investigate - Or to start the summit on the Sunday Oct 2nd and run it through Monday Oct 3rd, which I can investigate So really, it seems that Toronto is really the most viable option. And it seems that a majority for Toronto is emerging regardless Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 63662: tolerable FAIL - PUSHED
flight 63662 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/63662/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 63475 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 63475 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 63475 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail 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 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 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-amd64-i386-libvirt-xsm 12 migrate-support-checkfail 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-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass version targeted for testing: xen 6f04de658574833688c3f9eab310e7834d56a9c0 baseline version: xen e294a0c3af9f4443dc692b180fb1771b1cb075e8 Last test of basis63475 2015-11-02 05:45:42 Z4 days Failing since 63540 2015-11-03 16:02:15 Z2 days2 attempts Testing same since63662 2015-11-05 03:03:27 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Bob Liu Daniel De Graaf Dario Faggioli George Dunlap Harmandeep Kaur Ian Campbell Ian Jackson Jan Beulich Julien Grall Kevin Tian Kun Suo Olaf Hering Quan Xu Ross Lagerwall Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops
Re: [Xen-devel] [PATCH v11 5/5] xen/arm: account for stolen ticks
David Vrabel writes:
> On 06/11/15 11:39, Stefano Stabellini wrote:
>> On Thu, 5 Nov 2015, Mark Rutland wrote:
static void xen_percpu_init(void)
{
struct vcpu_register_vcpu_info info;
@@ -104,6 +120,8 @@ static void xen_percpu_init(void)
BUG_ON(err);
per_cpu(xen_vcpu, cpu) = vcpup;
+ xen_setup_runstate_info(cpu);
>>>
>>> Does the runstate memory area get unregsitered when a kernel tears
>>> things down, or is kexec somehow inhibited for xen guests?
>>>
>>> i couldn't spot either happening, but I may have missed it.
>>
>> I don't think that the runstate memory area needs to be unregistered for
>> kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly
>> and David.
>
> There's a whole pile of other state needing to be reset for kexec (event
> channels and grant tables for example). The guest needs to soft reset
> itself (available in Xen 4.6) before kexec'ing another kernel.
Unfortunately, it's 4.7. Soft reset patch series was merged after 4.6
freeze so it is only available in current master git branch.
>
> This soft reset would also including cleaning up this shared memory region.
>
> David
--
Vitaly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 5/5] xen/arm: account for stolen ticks
Mark Rutland writes:
> On Fri, Nov 06, 2015 at 11:41:49AM +, David Vrabel wrote:
>> On 06/11/15 11:39, Stefano Stabellini wrote:
>> > On Thu, 5 Nov 2015, Mark Rutland wrote:
>> >>> static void xen_percpu_init(void)
>> >>> {
>> >>> struct vcpu_register_vcpu_info info;
>> >>> @@ -104,6 +120,8 @@ static void xen_percpu_init(void)
>> >>> BUG_ON(err);
>> >>> per_cpu(xen_vcpu, cpu) = vcpup;
>> >>>
>> >>> +xen_setup_runstate_info(cpu);
>> >>
>> >> Does the runstate memory area get unregsitered when a kernel tears
>> >> things down, or is kexec somehow inhibited for xen guests?
>> >>
>> >> i couldn't spot either happening, but I may have missed it.
>> >
>> > I don't think that the runstate memory area needs to be unregistered for
>> > kexec, but I am not very knowledgeble on kexec and Xen, CC'ing Vitaly
>> > and David.
>>
>> There's a whole pile of other state needing to be reset for kexec (event
>> channels and grant tables for example). The guest needs to soft reset
>> itself (available in Xen 4.6) before kexec'ing another kernel.
>>
>> This soft reset would also including cleaning up this shared memory region.
>
> Ok. So we don't currently have the code kernel-side, but it looks like
> it would be relatively simple to add (having just spotted [1])
already merged in 4.3 and several stable trees.
> , and everything should be ready on the Xen side.`
>
Yes, but for x86 only. arch_domain_soft_reset() is -ENOSYS for ARM
now. It should be relatively easy to implement, one should unmap
shared_info page and do some GIC cleanup (if it's needed at all). I'd be
happy to help if someone's interested but unfortunately I don't have ARM
hardware to test at this moment...
> Thanks,
> Mark.
>
> [1] https://lkml.org/lkml/2015/9/25/152
--
Vitaly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC for-4.6 1/4] libxl: Move check for local access to a funciton
On Mon, Aug 10, 2015 at 08:11:22PM +0100, George Dunlap wrote:
> Move pygrub checks for local access ability into a separate function.
>
> Also reorganize libxl__device_disk_local_initiate_attach so that we
> don't initialize dls->disk unless we actually end up doing a local
> attach.
>
> Signed-off-by: George Dunlap
> ---
> CC: Ian Campbell
> CC: Ian Jackson
> CC: Wei Liu
> CC: Roger Pau Monne
> ---
> tools/libxl/libxl.c | 66
> +
> 1 file changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 083f099..e402c80 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3046,13 +3046,38 @@ static char * libxl__alloc_vdev(libxl__gc *gc, void
> *get_vdev_user,
>
> /* Callbacks */
>
> +static char * libxl__device_disk_find_local_path(libxl__gc *gc,
> + const libxl_device_disk
> *disk) {
> +char *path = NULL;
> +
> +/* No local paths for driver domains */
> +if (disk->backend_domname != NULL) {
> +LOG(DEBUG, "Non-local backend, can't access locally.\n");
> +goto out;
> +}
> +
> +/*
> + * If this is in raw format, and we're not using a script or a
> + * driver domain, we can access the target path directly.
> + */
> +if (disk->format == LIBXL_DISK_FORMAT_RAW
> +&& disk->script == NULL
> +&& disk->pdev_path) {
> +path = libxl__strdup(gc, disk->pdev_path);
> +LOG(DEBUG, "Directly accessing local RAW disk %s", path);
> +goto out;
> +}
> +
> + out:
> +return path;
> +}
> +
> static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev);
>
> void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
> libxl__disk_local_state *dls)
> {
> STATE_AO_GC(dls->ao);
> -char *dev = NULL;
> int rc;
> const libxl_device_disk *in_disk = dls->in_disk;
> libxl_device_disk *disk = &dls->disk;
> @@ -3060,34 +3085,35 @@ void
> libxl__device_disk_local_initiate_attach(libxl__egc *egc,
>
> assert(in_disk->pdev_path);
>
> -memcpy(disk, in_disk, sizeof(libxl_device_disk));
> -disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path);
> -if (in_disk->script != NULL)
> -disk->script = libxl__strdup(gc, in_disk->script);
> disk->vdev = NULL;
>
> -rc = libxl__device_disk_setdefault(gc, disk);
> -if (rc) goto out;
> +if(dls->diskpath)
Space after `if'.
> +LOG(DEBUG, "Strange, dls->diskpath already set: %s", dls->diskpath);
>
And if this is not expected, maybe just assert(!dls->diskpath) ?
> -/* If this is in a driver domain, or it's not a raw format, or it
> involves
> - * running a script, we have to do a local attach. */
> -if (disk->backend_domname != NULL
> -|| disk->format != LIBXL_DISK_FORMAT_RAW
> -|| disk->script != NULL) {
> +LOG(DEBUG, "Trying to find local path");
> +
> +if ((dls->diskpath = libxl__device_disk_find_local_path(gc, in_disk))) {
> +LOG(DEBUG, "Local path found, executing callback.");
> +dls->callback(egc, dls, 0);
> +} else {
> +LOG(DEBUG, "Local path not found, initiating attach.");
> +
> +memcpy(disk, in_disk, sizeof(libxl_device_disk));
> +disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path);
> +if (in_disk->script != NULL)
> +disk->script = libxl__strdup(gc, in_disk->script);
> +disk->vdev = NULL;
> +
> +rc = libxl__device_disk_setdefault(gc, disk);
> +if (rc) goto out;
> +
> +/* If we can't find a local path, attach it */
> libxl__prepare_ao_device(ao, &dls->aodev);
> dls->aodev.callback = local_device_attach_cb;
> device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk, &dls->aodev,
> libxl__alloc_vdev, (void *) blkdev_start);
> -return;
> }
>
> -LOG(DEBUG, "locally attaching RAW disk %s", disk->pdev_path);
> -dev = disk->pdev_path;
> -
> -if (dev != NULL)
> -dls->diskpath = libxl__strdup(gc, dev);
> -
> -dls->callback(egc, dls, 0);
> return;
>
> out:
> --
> 1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] arm: export platform_op XENPF_settime
On Thu, 5 Nov 2015, David Vrabel wrote: > On 05/11/15 16:57, Stefano Stabellini wrote: > > +case XENPF_settime32: > > +do_settime(op->u.settime32.secs, > > + op->u.settime32.nsecs, > > + op->u.settime32.system_time); > > +break; > > I don't think you want to provide this hypercall -- only provide the > XENPF_settime64 one. OK, make sense ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC for-4.6 1/4] libxl: Move check for local access to a funciton
This is sent by mistake. Please ignore this email until I finish the whole series. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen on Arm Arndale Exynos5250
Thanks for the help Ian, I tried using ttySAC2 in /etc/init/ttySAC2.conf but I still am not prompted to login on the serial output. I also tried creating /etc/init/ttyhvc0.conf. I think that is the correct place to start getty from. There are other similar files in that location and this page: https://help.ubuntu.com/community/SerialConsoleHowto says that karmic and newer start console processes from /etc/init/ files. I have also tried using /etc/inittab but that doesn't seem to help. The linaro prebuilt image (no xen) boots and I am prompted to log in so I tried comparing the boot process. I found that the boot.txt file on the boot partition had the following line: setenv bootargs "console=tty0 console=ttySAC2,115200n8 drm_kms_helper.edid_firmware=edid-1920x1080.fw root=UUID=bf05a5f4-06bf-4c99-8729-e20678372aea rootwait ro" that makes me confident that you are correct about the console name being ttySAC2. I tried editing my environment variables to be more similar to this as such: # setenv xen_bootargs 'console=dtuart dtuart=/serial@12C2 dom0_mem=512M' # setenv dom0_bootargs 'console=hvc0 console=ttySAC2,115200n8 ignore_loglevel psci=enable clk_ignore_unused root=/dev/mmcblk1p3' but that brings me to the same debug console with this instruction: (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) I can switch input to Xen and then I can get diagnostic info but that is a far as I get. On 11/06/2015 02:52 AM, Ian Campbell wrote: > On Thu, 2015-11-05 at 12:59 -0600, ed sandberg wrote: >> > >> My initial thought was that I needed to add a getty process on COM3, so >> that when I switched to Dom0 mode I could login. This page seems to >> agree with me: >> >> http://wiki.xenproject.org/wiki/Xen_Serial_Console >> >> I tried to do so by creating a ttyS2.conf file under /etc/init/ that >> read as follows: >> >> start on stopped rc RUNLEVEL=[2345] >> stop on runlevel [!2345] >> >> respawn >> exec /sbin/getty -8 115200 ttyS2 >> >> with that in place I was still not prompted to login but it had an >> effect because the serial connection would become unresponsive after a >> few minutes. > > IIRC Linux's name for the console serial device on Arndale is ttySAC2, > so that is what you would want when booting natively (unless Linaro > have done some pretty extreme patching, which I wouldn't expect. I've > only used mainline on this platform). > > If you are running as dom0 under Xen you want to have a getty on > "/dev/hvc0", the Xen PV console device, since the real UART will be > owned by Xen (due to the "dtuart=/serial@12C2" which you will be > passing on Xen's command line). > > I don't think any of the Arndale devices have multiple serial ports > exposed, but if they did then you could use separate ones for Xen's and > dom0's console, but the Linux name for dom0 would still be ttySAC > not ttyS. > > When you created /etc/init/ttyS2.conf were there other similar files > around in that directory? I ask because that sounds like an upstart > path and I'm unsure if Saucy still uses upstart. > > Ian. > > ___ > 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 2/3] xen/arm: introduce HYPERVISOR_dom0_op on arm and arm64
On Thu, 5 Nov 2015, Jan Beulich wrote: > >>> On 05.11.15 at 18:09, wrote: > > --- a/arch/arm/xen/hypercall.S > > +++ b/arch/arm/xen/hypercall.S > > @@ -89,6 +89,7 @@ HYPERCALL2(memory_op); > > HYPERCALL2(physdev_op); > > HYPERCALL3(vcpu_op); > > HYPERCALL1(tmem_op); > > +HYPERCALL1(dom0_op); > > Assuming this somehow tries to mirror x86 naming - time to rename it > there? I don't see why you'd want to introduce a dom0_op when it > has been renamed to platform_op many years ago - see > public/dom0_ops.h. In Linux it was never renamed. I could do that now as a precursor to this. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock
On Fri, 6 Nov 2015, Mark Rutland wrote: > > + delta = arch_timer_read_counter(); /* time since system boot */ > > + delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec; > > The arch counter value is not a number of nanoseconds (unless CNTFRQ > reads as 100), so this doesn't look right; the units don't match. That was a bad mistake. Thanks for catching it! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall
On Thu, 5 Nov 2015, David Vrabel wrote: > On 05/11/15 17:09, Stefano Stabellini wrote: > > If Linux is running as dom0, call XENPF_settime to update the system > > time in Xen on pvclock_gtod notifications. > > Isn't this a cut-and-paste from x86? Can you make it common? Not exactly, for the way system_time is set. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock
On Thu, 5 Nov 2015, Arnd Bergmann wrote:
> On Thursday 05 November 2015 17:09:43 Stefano Stabellini wrote:
> > Read the wallclock from the shared info page at boot time.
> >
> > Signed-off-by: Stefano Stabellini
>
> Please use the appropriate timespec64 based functions here,
> we are in the process of converting all callers of struct timespec.
OK, I can do that
> > ---
> > +static void xen_read_wallclock(struct timespec *ts)
> > +{
> > + u32 version;
> > + u64 delta;
> > + struct timespec now;
> > + struct shared_info *s = HYPERVISOR_shared_info;
> > + struct pvclock_wall_clock *wall_clock = &(s->wc);
>
> pvclock_wall_clock has a 'u32 sec', so that suffers from
> a potential overflow. We should try to avoid introducing that
> on ARM, and instead have a 64-bit seconds based version,
> or alternatively a 64-bit nanoseconds version (with no
> extra seconds) that is also sufficient.
Unfortunately this a preexisting ABI which is common with other existing
architectures (see arch/x86/kernel/pvclock.c:pvclock_read_wallclock). I
cannot just change it.
> > struct vcpu_register_vcpu_info info;
> > @@ -218,6 +246,7 @@ static int __init xen_guest_init(void)
> > struct shared_info *shared_info_page = NULL;
> > struct resource res;
> > phys_addr_t grant_frames;
> > + struct timespec ts;
> >
> > if (!xen_domain())
> > return 0;
> > @@ -291,6 +320,8 @@ static int __init xen_guest_init(void)
> >
> > pv_time_ops.steal_clock = xen_stolen_accounting;
> > static_key_slow_inc(¶virt_steal_enabled);
> > + xen_read_wallclock(&ts);
> > + do_settimeofday(&ts);
> >
>
> Once you can get a 64-bit time, call do_settimeofday64()
> here.
OK
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen on Arm Arndale Exynos5250
On Fri, 2015-11-06 at 08:38 -0600, ed sandberg wrote: Please don't top post. > Thanks for the help Ian, > # setenv xen_bootargs 'console=dtuart dtuart=/serial@12C2 > dom0_mem=512M' > # setenv dom0_bootargs 'console=hvc0 console=ttySAC2,115200n8 > ignore_loglevel psci=enable clk_ignore_unused root=/dev/mmcblk1p3' console=hvc0 in dom0_bootargs is correct when booting under Xen, ttySAC2 is not. ttySAC2 is only used when booting natively. Does your kernel have the Xen drivers (CONFIG_XEN and all which is gated on that) enabled. In particular CONFIG_HVC_XEN. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock
On Friday 06 November 2015 15:09:53 Stefano Stabellini wrote:
> > > ---
> > > +static void xen_read_wallclock(struct timespec *ts)
> > > +{
> > > + u32 version;
> > > + u64 delta;
> > > + struct timespec now;
> > > + struct shared_info *s = HYPERVISOR_shared_info;
> > > + struct pvclock_wall_clock *wall_clock = &(s->wc);
> >
> > pvclock_wall_clock has a 'u32 sec', so that suffers from
> > a potential overflow. We should try to avoid introducing that
> > on ARM, and instead have a 64-bit seconds based version,
> > or alternatively a 64-bit nanoseconds version (with no
> > extra seconds) that is also sufficient.
>
> Unfortunately this a preexisting ABI which is common with other existing
> architectures (see arch/x86/kernel/pvclock.c:pvclock_read_wallclock). I
> cannot just change it.
Maybe we need a "struct pvclock_wall_clock_v2"?
In theory, 'u32 sec' takes us all the way until 2106, which is significantly
longer away than the signed overflow in 2038, but it would still be nice
to not introduce this limitation on ARM in the first place.
I'm not quite sure about how the split between pvclock_wall_clock and
the delta works. Normally I'd expect that pvclock_wall_clock is the wallclock
time as it was at boot, while delta is the number of expired nanoseconds
since boot. However it is unclear why the latter has a longer range
(539 years starting at boot, rather than 126 years starting in 1970).
Arnd
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 08/21] xen/x86: allow disabling the emulated PIC
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v6:
- Return ENODEV in vpic_load if the vpic is disabled.
- Add asserts to vpic_irq_{negative/positive}_edge and vpic_ack_pending_irq
to make sure they are not called when the vpic is disabled.
- Add a check to vpic_reset in order to prevent calling it with the vpic
disabled.
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/hvm/vpic.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vpic.c b/xen/arch/x86/hvm/vpic.c
index 7c2edc8..6a2e87b 100644
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -377,6 +377,9 @@ static int vpic_save(struct domain *d, hvm_domain_context_t
*h)
struct hvm_hw_vpic *s;
int i;
+if ( !has_vpic(d) )
+return 0;
+
/* Save the state of both PICs */
for ( i = 0; i < 2 ; i++ )
{
@@ -392,7 +395,10 @@ static int vpic_load(struct domain *d,
hvm_domain_context_t *h)
{
struct hvm_hw_vpic *s;
uint16_t inst;
-
+
+if ( !has_vpic(d) )
+return -ENODEV;
+
/* Which PIC is this? */
inst = hvm_load_instance(h);
if ( inst > 1 )
@@ -412,6 +418,9 @@ void vpic_reset(struct domain *d)
{
struct hvm_hw_vpic *vpic;
+if ( !has_vpic(d) )
+return;
+
/* Master PIC. */
vpic = &d->arch.hvm_domain.vpic[0];
memset(vpic, 0, sizeof(*vpic));
@@ -425,6 +434,9 @@ void vpic_reset(struct domain *d)
void vpic_init(struct domain *d)
{
+if ( !has_vpic(d) )
+return;
+
vpic_reset(d);
register_portio_handler(d, 0x20, 2, vpic_intercept_pic_io);
@@ -439,6 +451,7 @@ void vpic_irq_positive_edge(struct domain *d, int irq)
struct hvm_hw_vpic *vpic = &d->arch.hvm_domain.vpic[irq >> 3];
uint8_t mask = 1 << (irq & 7);
+ASSERT(has_vpic(d));
ASSERT(irq <= 15);
ASSERT(vpic_is_locked(vpic));
@@ -456,6 +469,7 @@ void vpic_irq_negative_edge(struct domain *d, int irq)
struct hvm_hw_vpic *vpic = &d->arch.hvm_domain.vpic[irq >> 3];
uint8_t mask = 1 << (irq & 7);
+ASSERT(has_vpic(d));
ASSERT(irq <= 15);
ASSERT(vpic_is_locked(vpic));
@@ -473,6 +487,8 @@ int vpic_ack_pending_irq(struct vcpu *v)
int irq, vector;
struct hvm_hw_vpic *vpic = &v->domain->arch.hvm_domain.vpic[0];
+ASSERT(has_vpic(v->domain));
+
TRACE_2D(TRC_HVM_EMUL_PIC_PEND_IRQ_CALL, vlapic_accept_pic_intr(v),
vpic->int_output);
if ( !vlapic_accept_pic_intr(v) || !vpic->int_output )
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 03/21] xen/x86: allow disabling the emulated local apic
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Jan Beulich
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Eddie Dong
Cc: Kevin Tian
---
Changes since v7:
- Return 0 on vlapic_msr_set to note an error if the vlapic is disabled.
- Add Andrew Cooper Reviewed-by.
Changes since v6:
- Remove stall comments.
- Adds checks for has_vlapic in the msixtbl_pt_{un}register functions.
- Simplify the is_pvh_domain(d) || !has_vlapic(d) to !has_vlapic(d) when
appropriate.
- Split parts of this patch that can be considered bug fixes to a
pre-patch.
- Removed Acks since the patch changed substantially.
Changes since v5:
- Add Boris Ostrovsky Reviewed-by.
Changes since v4:
- Split the is_pvh_domain check into two, so part of the code can be shared
with the !has_lapic case.
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/hvm/vlapic.c | 27 ---
xen/arch/x86/hvm/vmsi.c | 12
xen/arch/x86/hvm/vmx/vmcs.c | 5 -
xen/arch/x86/hvm/vmx/vmx.c | 6 ++
4 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 0debe5e..417b1e7 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -993,6 +993,9 @@ static void set_x2apic_id(struct vlapic *vlapic)
bool_t vlapic_msr_set(struct vlapic *vlapic, uint64_t value)
{
+if ( !has_vlapic(vlapic_domain(vlapic)) )
+return 0;
+
if ( (vlapic->hw.apic_base_msr ^ value) & MSR_IA32_APICBASE_ENABLE )
{
if ( unlikely(value & MSR_IA32_APICBASE_EXTD) )
@@ -1205,6 +1208,9 @@ void vlapic_reset(struct vlapic *vlapic)
struct vcpu *v = vlapic_vcpu(vlapic);
int i;
+if ( !has_vlapic(v->domain) )
+return;
+
vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
vlapic_set_reg(vlapic, APIC_LVR, VLAPIC_VERSION);
@@ -1270,6 +1276,9 @@ static int lapic_save_hidden(struct domain *d,
hvm_domain_context_t *h)
struct vlapic *s;
int rc = 0;
+if ( !has_vlapic(d) )
+return 0;
+
for_each_vcpu ( d, v )
{
s = vcpu_vlapic(v);
@@ -1286,6 +1295,9 @@ static int lapic_save_regs(struct domain *d,
hvm_domain_context_t *h)
struct vlapic *s;
int rc = 0;
+if ( !has_vlapic(d) )
+return 0;
+
for_each_vcpu ( d, v )
{
if ( hvm_funcs.sync_pir_to_irr )
@@ -1333,7 +1345,10 @@ static int lapic_load_hidden(struct domain *d,
hvm_domain_context_t *h)
uint16_t vcpuid;
struct vcpu *v;
struct vlapic *s;
-
+
+if ( !has_vlapic(d) )
+return -ENODEV;
+
/* Which vlapic to load? */
vcpuid = hvm_load_instance(h);
if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
@@ -1365,7 +1380,10 @@ static int lapic_load_regs(struct domain *d,
hvm_domain_context_t *h)
uint16_t vcpuid;
struct vcpu *v;
struct vlapic *s;
-
+
+if ( !has_vlapic(d) )
+return -ENODEV;
+
/* Which vlapic to load? */
vcpuid = hvm_load_instance(h);
if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
@@ -1404,7 +1422,7 @@ int vlapic_init(struct vcpu *v)
HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
-if ( is_pvh_vcpu(v) )
+if ( !has_vlapic(v->domain) )
{
vlapic->hw.disabled = VLAPIC_HW_DISABLED;
return 0;
@@ -1457,6 +1475,9 @@ void vlapic_destroy(struct vcpu *v)
{
struct vlapic *vlapic = vcpu_vlapic(v);
+if ( !has_vlapic(v->domain) )
+return;
+
tasklet_kill(&vlapic->init_sipi.tasklet);
TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
destroy_periodic_time(&vlapic->pt);
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index ac838a9..499151e 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -391,6 +391,9 @@ int msixtbl_pt_register(struct domain *d, struct pirq
*pirq, uint64_t gtable)
ASSERT(spin_is_locked(&pcidevs_lock));
ASSERT(spin_is_locked(&d->event_lock));
+if ( !has_vlapic(d) )
+return -ENODEV;
+
/*
* xmalloc() with irq_disabled causes the failure of check_lock()
* for xenpool->lock. So we allocate an entry beforehand.
@@ -446,6 +449,9 @@ void msixtbl_pt_unregister(struct domain *d, struct pirq
*pirq)
ASSERT(spin_is_locked(&pcidevs_lock));
ASSERT(spin_is_locked(&d->event_lock));
+if ( !has_vlapic(d) )
+return;
+
irq_desc = pirq_spin_lock_irq_desc(pirq, NULL);
if ( !irq_desc )
return;
@@ -482,6 +488,9 @@ found:
void msixtbl_init(struct domain *d)
{
+if ( !has_vlapic(d) )
+return;
+
INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
@@ -493,6 +502,9 @@ void msixtbl_pt_cleanup(struct domain *d)
struct msixtbl_entry *entry, *temp;
unsigned long flags;
+if ( !has_vlapic(d) )
+return;
+
/* msixtbl_list_lock must be acquired with irq_disabled f
[Xen-devel] [PATCH v8 07/21] xen/x86: allow disabling the emulated IO APIC
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v6:
- Return ENODEV in ioapic_load if the ioapic is disabled.
- Add an assert to make sure vioapic_update_EOI and
vioapic_irq_positive_edge is only called when the vioapic is enabled.
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/hvm/vioapic.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index d348235..611be87 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -365,6 +365,8 @@ void vioapic_irq_positive_edge(struct domain *d, unsigned
int irq)
struct hvm_hw_vioapic *vioapic = domain_vioapic(d);
union vioapic_redir_entry *ent;
+ASSERT(has_vioapic(d));
+
HVM_DBG_LOG(DBG_LEVEL_IOAPIC, "irq %x", irq);
ASSERT(irq < VIOAPIC_NUM_PINS);
@@ -392,6 +394,8 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
union vioapic_redir_entry *ent;
int gsi;
+ASSERT(has_vioapic(d));
+
spin_lock(&d->arch.hvm_domain.irq_lock);
for ( gsi = 0; gsi < VIOAPIC_NUM_PINS; gsi++ )
@@ -424,12 +428,20 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
static int ioapic_save(struct domain *d, hvm_domain_context_t *h)
{
struct hvm_hw_vioapic *s = domain_vioapic(d);
+
+if ( !has_vioapic(d) )
+return 0;
+
return hvm_save_entry(IOAPIC, 0, h, s);
}
static int ioapic_load(struct domain *d, hvm_domain_context_t *h)
{
struct hvm_hw_vioapic *s = domain_vioapic(d);
+
+if ( !has_vioapic(d) )
+return -ENODEV;
+
return hvm_load_entry(IOAPIC, h, s);
}
@@ -440,6 +452,9 @@ void vioapic_reset(struct domain *d)
struct hvm_vioapic *vioapic = d->arch.hvm_domain.vioapic;
int i;
+if ( !has_vioapic(d) )
+return;
+
memset(&vioapic->hvm_hw_vioapic, 0, sizeof(vioapic->hvm_hw_vioapic));
for ( i = 0; i < VIOAPIC_NUM_PINS; i++ )
vioapic->hvm_hw_vioapic.redirtbl[i].fields.mask = 1;
@@ -448,6 +463,9 @@ void vioapic_reset(struct domain *d)
int vioapic_init(struct domain *d)
{
+if ( !has_vioapic(d) )
+return 0;
+
if ( (d->arch.hvm_domain.vioapic == NULL) &&
((d->arch.hvm_domain.vioapic = xmalloc(struct hvm_vioapic)) == NULL) )
return -ENOMEM;
@@ -462,6 +480,9 @@ int vioapic_init(struct domain *d)
void vioapic_deinit(struct domain *d)
{
+if ( !has_vioapic(d) )
+return;
+
xfree(d->arch.hvm_domain.vioapic);
d->arch.hvm_domain.vioapic = NULL;
}
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 09/21] xen/x86: set the vPMU interface based on the presence of a lapic
Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or not.
Signed-off-by: Roger Pau Monné
Signed-off-by: Boris Ostrovsky
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v7:
- Merge vpmu work from Boris.
Changes since v6:
- Major rework of the approach.
- Drop Andrew Cooper Acked-by.
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/cpu/vpmu.c | 11 ++-
xen/arch/x86/cpu/vpmu_amd.c | 6 +++---
xen/arch/x86/cpu/vpmu_intel.c | 6 +++---
xen/arch/x86/hvm/hvm.c| 2 ++
xen/arch/x86/hvm/svm/svm.c| 2 +-
xen/arch/x86/hvm/vmx/vmx.c| 2 +-
6 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 2f5156a..4346c66 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -94,7 +94,7 @@ void vpmu_lvtpc_update(uint32_t val)
vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
/* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
-if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
+if ( has_vlapic(curr->domain) || !vpmu->xenpmu_data ||
!vpmu_is_set(vpmu, VPMU_CACHED) )
apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
}
@@ -129,7 +129,7 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
* and since do_wr/rdmsr may load VPMU context we should save
* (and unload) it again.
*/
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+if ( !has_vlapic(curr->domain) && vpmu->xenpmu_data &&
vpmu_is_set(vpmu, VPMU_CACHED) )
{
vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
@@ -184,7 +184,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
return;
/* PV(H) guest */
-if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
+if ( !has_vlapic(sampling->domain) || (vpmu_mode & XENPMU_MODE_ALL) )
{
const struct cpu_user_regs *cur_regs;
uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
@@ -411,7 +411,8 @@ int vpmu_load(struct vcpu *v, bool_t from_guest)
/* Only when PMU is counting, we load PMU context immediately. */
if ( !vpmu_is_set(vpmu, VPMU_RUNNING) ||
- (!is_hvm_vcpu(vpmu_vcpu(vpmu)) && vpmu_is_set(vpmu, VPMU_CACHED)) )
+ (!has_vlapic(vpmu_vcpu(vpmu)->domain) &&
+ vpmu_is_set(vpmu, VPMU_CACHED)) )
return 0;
if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
@@ -635,7 +636,7 @@ long do_xenpmu_op(unsigned int op,
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
struct xen_pmu_data *xenpmu_data;
struct vpmu_struct *vpmu;
-if ( !opt_vpmu_enabled )
+if ( !opt_vpmu_enabled || has_vlapic(current->domain) )
return -EOPNOTSUPP;
ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 04da81a..990e6f3 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -238,7 +238,7 @@ static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
bool_t is_running = 0;
struct xen_pmu_amd_ctxt *guest_ctxt = &vpmu->xenpmu_data->pmu.c.amd;
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
ctxt = vpmu->context;
ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
@@ -314,7 +314,7 @@ static int amd_vpmu_save(struct vcpu *v, bool_t to_guest)
{
struct xen_pmu_amd_ctxt *guest_ctxt, *ctxt;
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
ctxt = vpmu->context;
guest_ctxt = &vpmu->xenpmu_data->pmu.c.amd;
memcpy(&guest_ctxt->regs[0], &ctxt->regs[0], regs_sz);
@@ -525,7 +525,7 @@ int svm_vpmu_initialise(struct vcpu *v)
vpmu->context = ctxt;
vpmu->priv_context = NULL;
-if ( !is_hvm_vcpu(v) )
+if ( !has_vlapic(v->domain) )
{
/* Copy register offsets to shared area */
ASSERT(vpmu->xenpmu_data);
diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 12f80ae..a9e0e68 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -337,7 +337,7 @@ static int core2_vpmu_save(struct vcpu *v, bool_t to_guest)
if ( to_guest )
{
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
memcpy((void *)(&vpmu->xenpmu_data->pmu.c.intel) + regs_off,
vpmu->context + regs_off, regs_sz);
}
@@ -442,7 +442,7 @@ static int core2_vpmu_load(struct vcpu *v, bool_t
from_guest)
{
int ret;
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
memcpy(vpmu->context + regs_off,
(void *)&v->arch.vpmu.xenpmu_data->pmu.c.intel + regs_off,
@@ -502,7 +502,7 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
vpmu->context = core2_vpmu_cxt;
vpmu->priv_context = p;
-if ( !is_hv
[Xen-devel] [PATCH v8 14/21] xen/x86: allow disabling all emulated devices inside of Xen
Only allow enabling or disabling all the emulated devices inside of Xen,
right now Xen doesn't support enabling specific emulated devices only.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v7:
- Rework if condition.
Changes since v5:
- Add Andrew Cooper Reviewed-by.
---
xen/arch/x86/domain.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3f9e5d2..971c88d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -532,8 +532,8 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
d->domain_id, config->emulation_flags);
return -EINVAL;
}
-if ( is_hvm_domain(d) ? (config->emulation_flags != XEN_X86_EMU_ALL)
- : (config->emulation_flags != 0) )
+if ( config->emulation_flags != 0 &&
+ (!is_hvm_domain(d) || config->emulation_flags != XEN_X86_EMU_ALL)
)
{
printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 13/21] xen/x86: make sure the HVM callback vector is correctly set
If certain devices (like the local or the io apic) are disabled some modes of operation of the HVM event channel callback cannot be used. Make sure Xen doesn't try to setup them. Signed-off-by: Roger Pau Monné Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/hvm/irq.c | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index 990a2ca..b5f5b05 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t via) (via_type > HVMIRQ_callback_vector) ) via_type = HVMIRQ_callback_none; +if ( via_type != HVMIRQ_callback_vector && + (!has_vlapic(d) || !has_vioapic(d)) ) +return; + spin_lock(&d->arch.hvm_domain.irq_lock); /* Tear down old callback via. */ -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 11/21] xen/x86: allow disabling the emulated IOMMU
Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper Acked-by: Aravind Gopalakrishnan Cc: Suravee Suthikulpanit Cc: Aravind Gopalakrishnan --- Changes since v4: - Add Andrew Cooper Acked-by. --- xen/drivers/passthrough/amd/iommu_guest.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/amd/iommu_guest.c b/xen/drivers/passthrough/amd/iommu_guest.c index e74f469..b4e75ac 100644 --- a/xen/drivers/passthrough/amd/iommu_guest.c +++ b/xen/drivers/passthrough/amd/iommu_guest.c @@ -887,7 +887,8 @@ int guest_iommu_init(struct domain* d) struct guest_iommu *iommu; struct hvm_iommu *hd = domain_hvm_iommu(d); -if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled ) +if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled || + !has_viommu(d) ) return 0; iommu = xzalloc(struct guest_iommu); -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 01/21] xen/x86: add bitmap of enabled emulated devices
Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or
disabling specific devices emulated inside of Xen for HVM guests.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
---
Changes since v7:
- Make the has_* macros actual booleans.
- Allow the idle domain to be created without an arch specific config.
- Check that PVH guests don't try to enable any emulated devices.
- Add a flag for disabling the PIT.
- Rename XEN_X86_EMU_PMTIMER into XEN_X86_EMU_PM and also rename the
related macro.
Changes since v6:
- Define XEN_X86_EMU_ALL to contain all the possible emulated devices.
- Remove full stops form the printks added to arch_domain_create.
- Add Wei Liu Acked-by.
- Added a check to x86 arch_domain_create in order to make sure a non-null
config is always provided.
- Check that emulation_flags is always 0 for PV guests.
- Fix x86 callers of domain_create in order to make sure a non-null arch
config is always provided.
- Removed XEN_X86_EMU_PMU.
- Removed Andrew Cooper's Reviewed-by, since the hypervisor side code has
changed substantially.
Changes since v4:
- Add a check to make sure the emulation bitmap is sane (undefined bits are
all 0s).
- Add Andrew Cooper Reviewed-by.
Changes since v3:
- Return EOPNOTSUPP instead of ENOPERM if an invalid emulation mask is
used.
- Fix error messages (prefix them with d%d and use %#x instead of 0x%x).
- Clearly state in the public header that emulation_flags should only be
used with HVM guests.
- Add a XEN_X86 prefix to the emulation flags defines.
- Properly parenthese the has_* marcos.
---
tools/libxl/libxl_x86.c | 5 -
xen/arch/x86/domain.c | 27 +++
xen/arch/x86/setup.c | 3 ++-
xen/common/schedule.c | 1 -
xen/include/asm-x86/domain.h | 13 +
xen/include/public/arch-x86/xen.h | 26 +-
6 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index c992261..183b6c2 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -7,7 +7,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
libxl_domain_config *d_config,
xc_domain_configuration_t *xc_config)
{
-/* No specific configuration right now */
+if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+xc_config->emulation_flags = XEN_X86_EMU_ALL;
+else
+xc_config->emulation_flags = 0;
return 0;
}
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index fe3be30..3f9e5d2 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -496,6 +496,9 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
int i, paging_initialised = 0;
int rc = -ENOMEM;
+if ( config == NULL && !is_idle_domain(d) )
+return -EINVAL;
+
d->arch.s3_integrity = !!(domcr_flags & DOMCRF_s3_integrity);
INIT_LIST_HEAD(&d->arch.pdev_list);
@@ -517,6 +520,30 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
d->domain_id);
}
+if ( is_idle_domain(d) )
+{
+d->arch.emulation_flags = 0;
+}
+else
+{
+if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+{
+printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
+ d->domain_id, config->emulation_flags);
+return -EINVAL;
+}
+if ( is_hvm_domain(d) ? (config->emulation_flags != XEN_X86_EMU_ALL)
+ : (config->emulation_flags != 0) )
+{
+printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
+ "with the current selection of emulators: %#x\n",
+ d->domain_id, is_hvm_domain(d) ? "HVM" : "PV",
+ config->emulation_flags);
+return -EOPNOTSUPP;
+}
+d->arch.emulation_flags = config->emulation_flags;
+}
+
if ( has_hvm_container_domain(d) )
{
d->arch.hvm_domain.hap_enabled =
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 4ed0110..6714473 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -582,6 +582,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
.parity= 'n',
.stop_bits = 1
};
+struct xen_arch_domainconfig config = { .emulation_flags = 0 };
/* Critical region without IDT or TSS. Any fault is deadly! */
@@ -1390,7 +1391,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
* x86 doesn't support arch-configuration. So it's fine to pass
* NULL.
*/
-dom0 = domain_create(0, domcr_flags, 0, NULL);
+dom0 = domain_create(0, domcr_flags,
[Xen-devel] [PATCH v8 16/21] libxc: allow creating domains without emulated devices.
Introduce a new flag in xc_dom_image that turns on and off the emulated
devices. This prevents creating the VGA hole, the hvm_info page and the
ioreq server pages. libxl unconditionally sets it to true for all HVM
domains at the moment.
Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
Reviewed-by: Andrew Cooper
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Changes since v5:
- Add Andrew Cooper Reviewed-by.
Changes since v4:
- Store the size of the VGA hole inside of the xc_dom_image struct and set
it from libxl.
- Rename dom->emulation to dom->device_model (no functional change).
- Add Wei Liu Acked-by.
Changes since v3:
- Explain the meaning of the "emulation" xc_dom_image field.
---
tools/libxc/include/xc_dom.h | 4 +++
tools/libxc/xc_dom_x86.c | 73
tools/libxl/libxl_dom.c | 2 ++
tools/libxl/libxl_internal.h | 1 +
4 files changed, 47 insertions(+), 33 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ccc5926..0f84600 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -190,6 +190,10 @@ struct xc_dom_image {
xen_paddr_t mmio_size;
xen_paddr_t lowmem_end;
xen_paddr_t highmem_end;
+xen_pfn_t vga_hole_size;
+
+/* If unset disables the setup of the IOREQ pages. */
+bool device_model;
/* Extra ACPI tables passed to HVMLOADER */
struct xc_hvm_firmware_module acpi_module;
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index ed43c28..63b4832 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -49,8 +49,6 @@
#define X86_CR0_PE 0x01
#define X86_CR0_ET 0x10
-#define VGA_HOLE_SIZE (0x20)
-
#define SPECIALPAGE_PAGING 0
#define SPECIALPAGE_ACCESS 1
#define SPECIALPAGE_SHARING 2
@@ -523,12 +521,15 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
xc_interface *xch = dom->xch;
-if ( (hvm_info_page = xc_map_foreign_range(
- xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
- HVM_INFO_PFN)) == NULL )
-goto error_out;
-build_hvm_info(hvm_info_page, dom);
-munmap(hvm_info_page, PAGE_SIZE);
+if ( dom->device_model )
+{
+if ( (hvm_info_page = xc_map_foreign_range(
+ xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ HVM_INFO_PFN)) == NULL )
+goto error_out;
+build_hvm_info(hvm_info_page, dom);
+munmap(hvm_info_page, PAGE_SIZE);
+}
/* Allocate and clear special pages. */
for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
@@ -560,30 +561,33 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
special_pfn(SPECIALPAGE_SHARING));
-/*
- * Allocate and clear additional ioreq server pages. The default
- * server will use the IOREQ and BUFIOREQ special pages above.
- */
-for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
-ioreq_server_array[i] = ioreq_server_pfn(i);
-
-rc = xc_domain_populate_physmap_exact(xch, domid, NR_IOREQ_SERVER_PAGES, 0,
- 0, ioreq_server_array);
-if ( rc != 0 )
+if ( dom->device_model )
{
-DOMPRINTF("Could not allocate ioreq server pages.");
-goto error_out;
-}
+/*
+ * Allocate and clear additional ioreq server pages. The default
+ * server will use the IOREQ and BUFIOREQ special pages above.
+ */
+for ( i = 0; i < NR_IOREQ_SERVER_PAGES; i++ )
+ioreq_server_array[i] = ioreq_server_pfn(i);
-if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
- NR_IOREQ_SERVER_PAGES) )
+rc = xc_domain_populate_physmap_exact(xch, domid,
NR_IOREQ_SERVER_PAGES, 0,
+ 0, ioreq_server_array);
+if ( rc != 0 )
+{
+DOMPRINTF("Could not allocate ioreq server pages.");
goto error_out;
+}
-/* Tell the domain where the pages are and how many there are */
-xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
- ioreq_server_pfn(0));
-xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
- NR_IOREQ_SERVER_PAGES);
+if ( xc_clear_domain_pages(xch, domid, ioreq_server_pfn(0),
+ NR_IOREQ_SERVER_PAGES) )
+goto error_out;
+
+/* Tell the domain where the pages are and how many there are */
+xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_SERVER_PFN,
+ ioreq_server_pfn(0));
+xc_hvm_param_set(xch, domid, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+ NR_IOREQ_SERVER_PAGES);
+}
/*
* Identity-map page table is require
[Xen-devel] [PATCH v8 20/21] libxl: allow the creation of HVM domains without a device model.
Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
builder now uses the PV xc_dom_* set of functions this kernel will be parsed
and loaded inside the guest like on PV, but the container is a pure HVM
guest.
Also, if device_model_version is set to none or a device model for the
specified domain is not present unconditinally set the nic type to
LIBXL_NIC_TYPE_VIF.
Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Changes since v7:
- Add LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE.
Changes since v5:
- Add Wei Liu Acked-by.
Changes since v4:
- Set dom->mmio_size to match the size of the special pages if there's no
device model for the guest. This implies moving NR_SPECIAL_PAGES and
X86_HVM_END_SPECIAL_REGION to a public header so they can be known by
libxl when creating the memory map.
- Reword the xl.cfg man page description of the "none" device model option.
- Use libxl__device_model_version_running instead of creating a new
function.
Changes since v3:
- Add explicit /* fall through */ comments.
- Expand libxl__device_nic_setdefault so that it sets the right nic type
for HVMlite guests.
- Remove stray space in hvm_build_set_params.
- Fix the error paths of libxl__domain_firmware.
---
docs/man/xl.cfg.pod.5| 5 +++
tools/libxc/include/xc_dom.h | 2 ++
tools/libxc/xc_dom_x86.c | 15 -
tools/libxl/libxl.c | 44 ++
tools/libxl/libxl.h | 8 +
tools/libxl/libxl_create.c | 16 +-
tools/libxl/libxl_dm.c | 3 +-
tools/libxl/libxl_dom.c | 74 ++--
tools/libxl/libxl_internal.h | 9 +-
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_x86.c | 15 ++---
tools/libxl/xl_cmdimpl.c | 2 ++
12 files changed, 144 insertions(+), 50 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index b63846a..54de01c 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1783,6 +1783,11 @@ This device-model is the default for Linux dom0.
Use the device-model based upon the historical Xen fork of Qemu.
This device-model is still the default for NetBSD dom0.
+=item B
+
+Don't use any device model. This requires a kernel capable of booting
+without emulated devices.
+
=back
It is recommended to accept the default value for new guests. If
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 0f84600..676858f 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -17,6 +17,8 @@
#include
#define INVALID_P2M_ENTRY ((xen_pfn_t)-1)
+#define X86_HVM_NR_SPECIAL_PAGES8
+#define X86_HVM_END_SPECIAL_REGION 0xff000u
/* --- typedefs and structs */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 7cf2a17..2f5c5a9 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -57,8 +57,8 @@
#define SPECIALPAGE_IOREQ5
#define SPECIALPAGE_IDENT_PT 6
#define SPECIALPAGE_CONSOLE 7
-#define NR_SPECIAL_PAGES 8
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+#define special_pfn(x) \
+(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES + (x))
#define NR_IOREQ_SERVER_PAGES 8
#define ioreq_server_pfn(x) (special_pfn(0) - NR_IOREQ_SERVER_PAGES + (x))
@@ -517,7 +517,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
void *hvm_info_page;
uint32_t *ident_pt, domid = dom->guest_domid;
int rc;
-xen_pfn_t special_array[NR_SPECIAL_PAGES];
+xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
xc_interface *xch = dom->xch;
@@ -532,18 +532,19 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
}
/* Allocate and clear special pages. */
-for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
special_array[i] = special_pfn(i);
-rc = xc_domain_populate_physmap_exact(xch, domid, NR_SPECIAL_PAGES, 0, 0,
- special_array);
+rc = xc_domain_populate_physmap_exact(xch, domid, X86_HVM_NR_SPECIAL_PAGES,
+ 0, 0, special_array);
if ( rc != 0 )
{
DOMPRINTF("Could not allocate special pages.");
goto error_out;
}
-if ( xc_clear_domain_pages(xch, domid, special_pfn(0), NR_SPECIAL_PAGES) )
+if ( xc_clear_domain_pages(xch, domid, special_pfn(0),
+ X86_HVM_NR_SPECIAL_PAGES) )
goto error_out;
xc_hvm_param_set(xch, domid, HVM_PARAM_STORE_PFN,
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 854e957..0284026 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1065,11 +1065,14 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
[Xen-devel] [PATCH v8 21/21] libxl: add support for migrating HVM guests without a device model
Only some minor libxl changes are needed in order to be able to migrate HVM
guests without a device model, no hypervisor changes are needed.
This change prevents sending the emulator context if the device model
version is set to none.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
Changes since v7:
- Prevent sending the emulator context and xenstore record in
write_emulator_context_record and write_emulator_xenstore_record.
- Error out if an emulator record is received for a no-dm guest.
---
tools/libxl/libxl_dom.c | 3 +++
tools/libxl/libxl_dom_suspend.c | 2 ++
tools/libxl/libxl_stream_read.c | 16
tools/libxl/libxl_stream_write.c | 16
4 files changed, 37 insertions(+)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 037d4dc..685eb25 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1315,6 +1315,9 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+break;
default:
LOG(ERROR,"logdirty switch failed"
", no valid device model version found, abandoning suspend");
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 4cc01ad..3313ad1 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -43,6 +43,8 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
if (ret)
unlink(filename);
break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+break;
default:
return ERROR_INVAL;
}
diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c
index 4ec29da..258dec4 100644
--- a/tools/libxl/libxl_stream_read.c
+++ b/tools/libxl/libxl_stream_read.c
@@ -539,6 +539,14 @@ static bool process_record(libxl__egc *egc,
break;
case REC_TYPE_EMULATOR_XENSTORE_DATA:
+if (dcs->guest_config->b_info.device_model_version ==
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+rc = ERROR_FAIL;
+LOG(ERROR,
+"Received a xenstore emulator record when none was expected");
+goto err;
+}
+
if (rec->hdr.length < sizeof(libxl__sr_emulator_hdr)) {
rc = ERROR_FAIL;
LOG(ERROR,
@@ -560,6 +568,14 @@ static bool process_record(libxl__egc *egc,
break;
case REC_TYPE_EMULATOR_CONTEXT:
+if (dcs->guest_config->b_info.device_model_version ==
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+rc = ERROR_FAIL;
+LOG(ERROR,
+"Received an emulator context record when none was expected");
+goto err;
+}
+
write_emulator_blob(egc, stream, rec);
break;
diff --git a/tools/libxl/libxl_stream_write.c b/tools/libxl/libxl_stream_write.c
index 52a60d7..0a6eaf9 100644
--- a/tools/libxl/libxl_stream_write.c
+++ b/tools/libxl/libxl_stream_write.c
@@ -232,6 +232,9 @@ void libxl__stream_write_start(libxl__egc *egc,
stream->emu_sub_hdr.id = EMULATOR_QEMU_UPSTREAM;
break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+break;
+
default:
rc = ERROR_FAIL;
LOG(ERROR, "Unknown emulator for HVM domain");
@@ -359,6 +362,12 @@ static void write_emulator_xenstore_record(libxl__egc *egc,
char *buf = NULL;
uint32_t len = 0;
+if (libxl__device_model_version_running(gc, dss->domid) ==
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+emulator_xenstore_record_done(egc, stream);
+return;
+}
+
rc = libxl__save_emulator_xenstore_data(dss, &buf, &len);
if (rc)
goto err;
@@ -387,6 +396,7 @@ static void emulator_xenstore_record_done(libxl__egc *egc,
libxl__stream_write_state *stream)
{
libxl__domain_suspend_state *dss = stream->dss;
+STATE_AO_GC(stream->ao);
if (dss->type == LIBXL_DOMAIN_TYPE_HVM)
write_emulator_context_record(egc, stream);
@@ -410,6 +420,12 @@ static void write_emulator_context_record(libxl__egc *egc,
assert(dss->type == LIBXL_DOMAIN_TYPE_HVM);
+if (libxl__device_model_version_running(gc, dss->domid) ==
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+emulator_context_record_done(egc, stream);
+return;
+}
+
/* Convenience aliases */
const char *const filename = dss->dm_savefile;
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 04/21] xen/x86: allow disabling the emulated HPET
Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v6: - Return ENODEV in hpet_load if the vhpet is disabled. Changes since v4: - Add Andrew Cooper Acked-by. --- xen/arch/x86/hvm/hpet.c | 13 + xen/arch/x86/hvm/hvm.c | 1 - 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c index facab83..5e020ae 100644 --- a/xen/arch/x86/hvm/hpet.c +++ b/xen/arch/x86/hvm/hpet.c @@ -517,6 +517,9 @@ static int hpet_save(struct domain *d, hvm_domain_context_t *h) int rc; uint64_t guest_time; +if ( !has_vhpet(d) ) +return 0; + write_lock(&hp->lock); guest_time = (v->arch.hvm_vcpu.guest_time ?: hvm_get_guest_time(v)) / STIME_PER_HPET_TICK; @@ -577,6 +580,9 @@ static int hpet_load(struct domain *d, hvm_domain_context_t *h) uint64_t guest_time; int i; +if ( !has_vhpet(d) ) +return -ENODEV; + write_lock(&hp->lock); /* Reload the HPET registers */ @@ -635,6 +641,9 @@ void hpet_init(struct domain *d) HPETState *h = domain_vhpet(d); int i; +if ( !has_vhpet(d) ) +return; + memset(h, 0, sizeof(HPETState)); rwlock_init(&h->lock); @@ -662,6 +671,7 @@ void hpet_init(struct domain *d) } register_mmio_handler(d, &hpet_mmio_ops); +d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1; } void hpet_deinit(struct domain *d) @@ -669,6 +679,9 @@ void hpet_deinit(struct domain *d) int i; HPETState *h = domain_vhpet(d); +if ( !has_vhpet(d) ) +return; + write_lock(&h->lock); if ( hpet_enabled(h) ) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 21f42a7..4490e9d 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1605,7 +1605,6 @@ int hvm_domain_initialise(struct domain *d) hvm_init_guest_time(d); -d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1; d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot; vpic_init(d); -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 05/21] xen/x86: allow disabling power management
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v7:
- Add Andrew Cooper Reviewed-by.
- Apply renaming from earlier patch (s/PMTIMER/PM/).
Changes since v6:
- Return ENODEV in pmtimer_load if the timer is disabled.
- hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the
pmtimer is disabled.
- Return ENODEV if pmtimer_change_ioport is called with the pmtimer
disabled.
- Add a check for disabled pmtimer in pmtimer_reset. Although it's safe to
execute this function now, it might change in the future.
- Drop Andrew's Ack due to the changes.
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/hvm/pmtimer.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/xen/arch/x86/hvm/pmtimer.c b/xen/arch/x86/hvm/pmtimer.c
index c8229e0..9c2e4bd 100644
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -67,6 +67,10 @@ static void pmt_update_sci(PMTState *s)
void hvm_acpi_power_button(struct domain *d)
{
PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
+
+if ( !has_vpm(d) )
+return;
+
spin_lock(&s->lock);
s->pm.pm1a_sts |= PWRBTN_STS;
pmt_update_sci(s);
@@ -76,6 +80,10 @@ void hvm_acpi_power_button(struct domain *d)
void hvm_acpi_sleep_button(struct domain *d)
{
PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
+
+if ( !has_vpm(d) )
+return;
+
spin_lock(&s->lock);
s->pm.pm1a_sts |= SLPBTN_STS;
pmt_update_sci(s);
@@ -247,6 +255,9 @@ static int pmtimer_save(struct domain *d,
hvm_domain_context_t *h)
uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
int rc;
+if ( !has_vpm(d) )
+return 0;
+
spin_lock(&s->lock);
/*
@@ -273,6 +284,9 @@ static int pmtimer_load(struct domain *d,
hvm_domain_context_t *h)
{
PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
+if ( !has_vpm(d) )
+return -ENODEV;
+
spin_lock(&s->lock);
/* Reload the registers */
@@ -301,6 +315,9 @@ int pmtimer_change_ioport(struct domain *d, unsigned int
version)
{
unsigned int old_version;
+if ( !has_vpm(d) )
+return -ENODEV;
+
/* Check that version is changing. */
old_version = d->arch.hvm_domain.params[HVM_PARAM_ACPI_IOPORTS_LOCATION];
if ( version == old_version )
@@ -330,6 +347,9 @@ void pmtimer_init(struct vcpu *v)
{
PMTState *s = &v->domain->arch.hvm_domain.pl_time.vpmt;
+if ( !has_vpm(v->domain) )
+return;
+
spin_lock_init(&s->lock);
s->scale = ((uint64_t)FREQUENCE_PMTIMER << 32) / SYSTEM_TIME_HZ;
@@ -350,11 +370,18 @@ void pmtimer_init(struct vcpu *v)
void pmtimer_deinit(struct domain *d)
{
PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
+
+if ( !has_vpm(d) )
+return;
+
kill_timer(&s->timer);
}
void pmtimer_reset(struct domain *d)
{
+if ( !has_vpm(d) )
+return;
+
/* Reset the counter. */
d->arch.hvm_domain.pl_time.vpmt.pm.tmr_val = 0;
}
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 19/21] libxc: switch xc_dom_elfloader to be used with HVMlite domains
Allow xc_dom_elfloader to report a guest type as hvm-3.0-x86_32 if it's
running inside of a HVM container and has the PHYS32_ENTRY elfnote set.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Only xc_dom_elfloader has been switched to support HVMlite, other loaders
should also be switched once we have a HVMlite compatible kernel that uses
them.
---
Changes since v5:
- Add Wei Liu Ack.
Changes since v4:
- Add Andrew Cooper Reviewed-by.
---
tools/libxc/xc_dom_elfloader.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 36a115e..2ae575e 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -56,6 +56,10 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
{
uint64_t machine = elf_uval(elf, elf->ehdr, e_machine);
+if ( dom->container_type == XC_DOM_HVM_CONTAINER &&
+ dom->parms.phys_entry != UNSET_ADDR )
+return "hvm-3.0-x86_32";
+
switch ( machine )
{
case EM_386:
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 06/21] xen/x86: allow disabling the emulated RTC
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v6:
- Return ENODEV in rtc_load if rtc is disabled.
- Add checks to rtc_reset and rtc_update_clock to prevent calling them if
rtc is disabled.
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/hvm/rtc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c
index a9efeaf..d391e38 100644
--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -726,6 +726,9 @@ void rtc_migrate_timers(struct vcpu *v)
{
RTCState *s = vcpu_vrtc(v);
+if ( !has_vrtc(v->domain) )
+return;
+
if ( v->vcpu_id == 0 )
{
migrate_timer(&s->update_timer, v->processor);;
@@ -739,6 +742,10 @@ static int rtc_save(struct domain *d, hvm_domain_context_t
*h)
{
RTCState *s = domain_vrtc(d);
int rc;
+
+if ( !has_vrtc(d) )
+return 0;
+
spin_lock(&s->lock);
rc = hvm_save_entry(RTC, 0, h, &s->hw);
spin_unlock(&s->lock);
@@ -750,6 +757,9 @@ static int rtc_load(struct domain *d, hvm_domain_context_t
*h)
{
RTCState *s = domain_vrtc(d);
+if ( !has_vrtc(d) )
+return -ENODEV;
+
spin_lock(&s->lock);
/* Restore the registers */
@@ -780,6 +790,9 @@ void rtc_reset(struct domain *d)
{
RTCState *s = domain_vrtc(d);
+if ( !has_vrtc(d) )
+return;
+
TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
destroy_periodic_time(&s->pt);
s->period = 0;
@@ -790,6 +803,9 @@ void rtc_init(struct domain *d)
{
RTCState *s = domain_vrtc(d);
+if ( !has_vrtc(d) )
+return;
+
spin_lock_init(&s->lock);
init_timer(&s->update_timer, rtc_update_timer, s, smp_processor_id());
@@ -820,6 +836,9 @@ void rtc_deinit(struct domain *d)
{
RTCState *s = domain_vrtc(d);
+if ( !has_vrtc(d) )
+return;
+
spin_barrier(&s->lock);
TRACE_0D(TRC_HVM_EMUL_RTC_STOP_TIMER);
@@ -833,6 +852,9 @@ void rtc_update_clock(struct domain *d)
{
RTCState *s = domain_vrtc(d);
+if ( !has_vrtc(d) )
+return;
+
spin_lock(&s->lock);
s->current_tm = gmtime(get_localtime(d));
spin_unlock(&s->lock);
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 10/21] xen/x86: allow disabling the emulated VGA
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v4:
- Add Andrew Cooper Acked-by.
---
xen/arch/x86/hvm/stdvga.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/hvm/stdvga.c b/xen/arch/x86/hvm/stdvga.c
index 02a97f9..ae1c2d0 100644
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -554,6 +554,9 @@ void stdvga_init(struct domain *d)
struct page_info *pg;
unsigned int i;
+if ( !has_vvga(d) )
+return;
+
memset(s, 0, sizeof(*s));
spin_lock_init(&s->lock);
@@ -591,6 +594,9 @@ void stdvga_deinit(struct domain *d)
struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
int i;
+if ( !has_vvga(d) )
+return;
+
for ( i = 0; i != ARRAY_SIZE(s->vram_page); i++ )
{
if ( s->vram_page[i] == NULL )
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 02/21] xen/vlapic: fixes for HVM code when running without a vlapic
The HVM related code (SVM, VMX) generally assumed that a local apic is
always present. With the introduction of a HVM mode were the local apic can
be removed, some of this broken code paths arised.
The SVM exit/resume paths unconditionally checked the state of the lapic,
which is wrong if it's been disabled by hardware, fix this by adding the
necessary checks. On the VMX side, make sure we don't add mappings for a
local apic if it's disabled.
In the generic vlapic code, add checks to prevent setting the TSC deadline
timer if the lapic is disabled, and also prevent trying to inject interrupts
from the PIC is the lapic is also disabled.
Signed-off-by: Roger Pau Monné
Reviewed-by: Boris Ostrovsky
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Aravind Gopalakrishnan
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Eddie Dong
Cc: Kevin Tian
---
Changes since v7:
- Only check apic_access_mfn in vmx_install_vlapic_mapping, and add an
assert.
- Return 0 (instead of -ENODEV) in vlapic_accept_pic_intr if the vlapic is
disabled.
- Add Boris Ostrovsky Reviewed-by tag.
---
xen/arch/x86/hvm/svm/svm.c | 18 ++
xen/arch/x86/hvm/vlapic.c | 7 ++-
xen/arch/x86/hvm/vmx/vmx.c | 4 +++-
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8de41fa..404634b 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1035,6 +1035,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
bool_t debug_state = v->domain->debugger_attached;
bool_t vcpu_guestmode = 0;
+struct vlapic *vlapic = vcpu_vlapic(v);
if ( nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v) )
vcpu_guestmode = 1;
@@ -1058,14 +1059,14 @@ static void noreturn svm_do_resume(struct vcpu *v)
hvm_asid_flush_vcpu(v);
}
-if ( !vcpu_guestmode )
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
{
vintr_t intr;
/* Reflect the vlapic's TPR in the hardware vtpr */
intr = vmcb_get_vintr(vmcb);
intr.fields.tpr =
-(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
+(vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xFF) >> 4;
vmcb_set_vintr(vmcb, intr);
}
@@ -2294,6 +2295,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
int inst_len, rc;
vintr_t intr;
bool_t vcpu_guestmode = 0;
+struct vlapic *vlapic = vcpu_vlapic(v);
hvm_invalidate_regs_fields(regs);
@@ -2311,11 +2313,12 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
* NB. We need to preserve the low bits of the TPR to make checked builds
* of Windows work, even though they don't actually do anything.
*/
-if ( !vcpu_guestmode ) {
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
+{
intr = vmcb_get_vintr(vmcb);
-vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
+vlapic_set_reg(vlapic, APIC_TASKPRI,
((intr.fields.tpr & 0x0F) << 4) |
- (vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0x0F));
+ (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0x0F));
}
exit_reason = vmcb->exitcode;
@@ -2697,14 +2700,13 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
}
out:
-if ( vcpu_guestmode )
-/* Don't clobber TPR of the nested guest. */
+if ( vcpu_guestmode || vlapic_hw_disabled(vlapic) )
return;
/* The exit may have updated the TPR: reflect this in the hardware vtpr */
intr = vmcb_get_vintr(vmcb);
intr.fields.tpr =
-(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
+(vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xFF) >> 4;
vmcb_set_vintr(vmcb, intr);
}
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index b893b40..0debe5e 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1042,7 +1042,9 @@ void vlapic_tdt_msr_set(struct vlapic *vlapic, uint64_t
value)
uint64_t guest_tsc;
struct vcpu *v = vlapic_vcpu(vlapic);
-/* may need to exclude some other conditions like vlapic->hw.disabled */
+if ( vlapic_hw_disabled(vlapic) )
+return;
+
if ( !vlapic_lvtt_tdt(vlapic) )
{
HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "ignore tsc deadline msr write");
@@ -1118,6 +1120,9 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
int vlapic_accept_pic_intr(struct vcpu *v)
{
+if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+return 0;
+
TRACE_2D(TRC_HVM_EMUL_LAPIC_PIC_INTR,
(v == v->domain->arch.hvm_domain.i8259_target),
v ? __vlapic_accept_pic_intr(v) : -1);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bbec0e8..fcfd70b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2412,9 +2412,11 @@ static void vmx_
[Xen-devel] [PATCH v8 12/21] xen/x86: allow disabling the emulated PIT
Signed-off-by: Roger Pau Monné
Reported by: Boris Ostrovsky
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v7:
- Patch added.
---
xen/arch/x86/hvm/i8254.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/xen/arch/x86/hvm/i8254.c b/xen/arch/x86/hvm/i8254.c
index 8a93c88..b517cd6 100644
--- a/xen/arch/x86/hvm/i8254.c
+++ b/xen/arch/x86/hvm/i8254.c
@@ -382,6 +382,9 @@ static uint32_t pit_ioport_read(struct PITState *pit,
uint32_t addr)
void pit_stop_channel0_irq(PITState *pit)
{
+if ( !has_vpit(current->domain) )
+return;
+
TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
spin_lock(&pit->lock);
destroy_periodic_time(&pit->pt0);
@@ -393,6 +396,9 @@ static int pit_save(struct domain *d, hvm_domain_context_t
*h)
PITState *pit = domain_vpit(d);
int rc;
+if ( !has_vpit(d) )
+return 0;
+
spin_lock(&pit->lock);
rc = hvm_save_entry(PIT, 0, h, &pit->hw);
@@ -407,6 +413,9 @@ static int pit_load(struct domain *d, hvm_domain_context_t
*h)
PITState *pit = domain_vpit(d);
int i;
+if ( !has_vpit(d) )
+return -ENODEV;
+
spin_lock(&pit->lock);
if ( hvm_load_entry(PIT, h, &pit->hw) )
@@ -437,6 +446,9 @@ void pit_reset(struct domain *d)
struct hvm_hw_pit_channel *s;
int i;
+if ( !has_vpit(d) )
+return;
+
TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
destroy_periodic_time(&pit->pt0);
pit->pt0.source = PTSRC_isa;
@@ -458,6 +470,9 @@ void pit_init(struct domain *d, unsigned long cpu_khz)
{
PITState *pit = domain_vpit(d);
+if ( !has_vpit(d) )
+return;
+
spin_lock_init(&pit->lock);
if ( is_hvm_domain(d) )
@@ -473,6 +488,9 @@ void pit_deinit(struct domain *d)
{
PITState *pit = domain_vpit(d);
+if ( !has_vpit(d) )
+return;
+
TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
destroy_periodic_time(&pit->pt0);
}
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 15/21] elfnotes: intorduce a new PHYS_ENTRY elfnote
This new elfnote contains the 32bit entry point into the kernel. Xen will
use this entry point in order to launch the guest kernel in 32bit protected
mode with paging disabled.
Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
Reviewed-by: Andrew Cooper
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
Changes since v6:
- Reword a comment.
Changes since v4:
- Add Andrew Cooper Reviewed-by and Wei Liu Acked-by.
---
tools/xcutils/readnotes.c | 3 +++
xen/common/libelf/libelf-dominfo.c | 4
xen/include/public/elfnote.h | 12 +++-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/xcutils/readnotes.c b/tools/xcutils/readnotes.c
index 5fa445e..e682dd1 100644
--- a/tools/xcutils/readnotes.c
+++ b/tools/xcutils/readnotes.c
@@ -159,6 +159,9 @@ static unsigned print_notes(struct elf_binary *elf,
ELF_HANDLE_DECL(elf_note) st
case XEN_ELFNOTE_L1_MFN_VALID:
print_l1_mfn_valid_note("L1_MFN_VALID", elf , note);
break;
+ case XEN_ELFNOTE_PHYS32_ENTRY:
+ print_numeric_note("PHYS32_ENTRY", elf , note);
+ break;
default:
printf("unknown note type %#x\n",
(unsigned)elf_uval(elf, note, type));
diff --git a/xen/common/libelf/libelf-dominfo.c
b/xen/common/libelf/libelf-dominfo.c
index 3de1c23..dacd4ba 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -119,6 +119,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
[XEN_ELFNOTE_BSD_SYMTAB] = { "BSD_SYMTAB", 1},
[XEN_ELFNOTE_SUSPEND_CANCEL] = { "SUSPEND_CANCEL", 0 },
[XEN_ELFNOTE_MOD_START_PFN] = { "MOD_START_PFN", 0 },
+[XEN_ELFNOTE_PHYS32_ENTRY] = { "PHYS32_ENTRY", 0 },
};
/* *INDENT-ON* */
@@ -212,6 +213,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
elf, note, sizeof(*parms->f_supported), i);
break;
+case XEN_ELFNOTE_PHYS32_ENTRY:
+parms->phys_entry = val;
+break;
}
return 0;
}
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 3824a94..353985f 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -200,9 +200,19 @@
#define XEN_ELFNOTE_SUPPORTED_FEATURES 17
/*
+ * Physical entry point into the kernel.
+ *
+ * 32bit entry point into the kernel. When requested to launch the
+ * guest kernel in a HVM container, Xen will use this entry point to
+ * launch the guest in 32bit protected mode with paging disabled.
+ * Ignored otherwise.
+ */
+#define XEN_ELFNOTE_PHYS32_ENTRY 18
+
+/*
* The number of the highest elfnote defined.
*/
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_SUPPORTED_FEATURES
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
/*
* System information exported through crash notes.
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 00/21] Introduce HVM without dm and new boot ABI
This series is split in the following order: - Patches from 1 to 12 allow disabling the devices emulated inside of Xen, with the exception of patch 2 which is a bugfix for the vlapic. - Patches from 13 to 21 introduce the creation of HVM guests without a device model and without the devices emulated inside of Xen. This series has been successfully tested on the following hardware: - Intel Core i3-5010U. - AMD Opteron 4184. With both hap=0 and hap=1 in the configuration file. I've been able to boot a SMP guest in this mode with a virtual hard drive and a virtual network card, all working fine AFAICT. Migration/save/restore has also been tested with a SMP guest using the FreeBSD kernel provided below. The series has been compile tested on arm32. The series can also be found in the following git repo: git://xenbits.xen.org/people/royger/xen.git branch hvm_without_dm_v8 And for the FreeBSD part: git://xenbits.xen.org/people/royger/freebsd.git branch new_entry_point_v5 In case someone wants to give it a try, I've uploaded a FreeBSD kernel that should work when booted into this mode: https://people.freebsd.org/~royger/kernel_no_dm This FreeBSD kernel starts the APs in long mode. There are examples for starting the APs in other modes in the sys/x86/xen/pv.c file. The config file that I've used is: kernel="/path/to/kernel_no_dm" builder="hvm" device_model_version="none" memory=128 vcpus=2 name = "freebsd" Of course if you have a FreeBSD disk already setup it can also be added to the configuration file, and the following line can be used to point FreeBSD to the disk: extra="vfs.root.mountfrom=ufs:/dev/ufsid/" As usual, each patch has it's own changelog. AW M 01/21 xen/x86: add bitmap of enabled emulated devices B M 02/21 xen/vlapic: fixes for HVM code when running without A J M 03/21 xen/x86: allow disabling the emulated local apic A 04/21 xen/x86: allow disabling the emulated HPET AM 05/21 xen/x86: allow disabling power management A 06/21 xen/x86: allow disabling the emulated RTC A 07/21 xen/x86: allow disabling the emulated IO APIC A 08/21 xen/x86: allow disabling the emulated PIC M 09/21 xen/x86: set the vPMU interface based on the A 10/21 xen/x86: allow disabling the emulated VGA A 11/21 xen/x86: allow disabling the emulated IOMMU N 12/21 xen/x86: allow disabling the emulated PIT M 13/21 xen/x86: make sure the HVM callback vector is AM 14/21 xen/x86: allow disabling all emulated devices inside AW 15/21 elfnotes: intorduce a new PHYS_ENTRY elfnote AW 16/21 libxc: allow creating domains without emulated M 17/21 xen/x86: allow HVM guests to use hypercalls to bring AW M 18/21 libxc/xen: introduce a start info structure for AW 19/21 libxc: switch xc_dom_elfloader to be used with W 20/21 libxl: allow the creation of HVM domains without a M 21/21 libxl: add support for migrating HVM guests without A = Acked/Reviewed by Andrew Cooper. W = Acked/Reviewed by Wei Liu. J = Acked/Reviewed by Jan Beulich. N = New in this version. M = Modified in this version. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 17/21] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
VCPUOP_is_up hypercalls from HVM guests.
This patch introduces a new structure (vcpu_hvm_context) that should be used
in conjuction with the VCPUOP_initialise hypercall in order to initialize
vCPUs for HVM guests.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Campbell
Cc: Stefano Stabellini
---
Changes since v7:
- Improved error messages.
- Set EFER.LMA if EFER.LME is set by the user.
- Fix calculation of CS limit.
- Add more checks to segment registers.
- Add checks to make sure padding fields are 0.
- Remove ugly arch ifdefs from common domain.c.
- Add the implicit padding of vcpu_hvm_x86_32 explicitly in the structure.
- Simplify the compat vcpu code since it's only used on x86.
Changes since v6:
- Add comments to clarify some initializations.
- Introduce a generic default_initialize_vcpu that's used to initialize a
ARM vCPU or a x86 PV vCPU.
- Move the undef of the SEG macro.
- Fix the size of the eflags register, it should be 32bits.
- Add a comment regarding the value of the 12-15 bits of the _ar fields.
- Remove the 16bit strucutre, the 32bit one can be used to start the cpu in
real mode.
- Add some sanity checks to the values passed in.
- Add paddings to vcpu_hvm_context so the layout on 32/64bits is the same.
- Add support for the compat version of VCPUOP_initialise.
Changes since v5:
- Fix a coding style issue.
- Merge the code from wip-dmlite-v5-refactor by Andrew in order to reduce
bloat.
- Print the offending %cr3 in case of error when using shadow.
- Reduce the scope of local variables in arch_initialize_vcpu.
- s/current->domain/v->domain/g in arch_initialize_vcpu.
- Expand the comment in public/vcpu.h to document the usage of
vcpu_hvm_context for HVM guests.
- Add myself as the copyright holder for the public hvm_vcpu.h header.
Changes since v4:
- Don't assume mode is 64B, add an explicit check.
- Don't set TF_kernel_mode, it is only needed for PV guests.
- Don't set CR0_ET unconditionally.
---
xen/arch/arm/domain.c | 24
xen/arch/x86/domain.c | 296 ++
xen/arch/x86/hvm/hvm.c| 8 ++
xen/common/compat/domain.c| 50 +--
xen/common/domain.c | 17 +--
xen/include/Makefile | 1 +
xen/include/asm-x86/domain.h | 3 +
xen/include/public/hvm/hvm_vcpu.h | 144 +++
xen/include/public/vcpu.h | 6 +-
xen/include/xen/domain.h | 2 +
xen/include/xlat.lst | 3 +
11 files changed, 521 insertions(+), 33 deletions(-)
create mode 100644 xen/include/public/hvm/hvm_vcpu.h
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 880d0a6..7fe4dd8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -754,6 +754,30 @@ int arch_set_info_guest(
return 0;
}
+int arch_initialize_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct vcpu_guest_context *ctxt;
+struct domain *d = v->domain;
+int rc;
+
+if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
+return -ENOMEM;
+
+if ( copy_from_guest(ctxt, arg, 1) )
+{
+free_vcpu_guest_context(ctxt);
+return -EFAULT;
+}
+
+domain_lock(d);
+rc = v->is_initialised ? -EEXIST : arch_set_info_guest(v, ctxt);
+domain_unlock(d);
+
+free_vcpu_guest_context(ctxt);
+
+return rc;
+}
+
int arch_vcpu_reset(struct vcpu *v)
{
vcpu_end_shutdown_deferral(v);
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 971c88d..a6775c9 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1183,6 +1184,301 @@ int arch_set_info_guest(
#undef c
}
+static inline int check_segment(struct segment_register reg,
+enum x86_segment seg)
+{
+
+if ( reg.attr.fields.pad != 0 )
+{
+gprintk(XENLOG_ERR,
+"Attribute bits 12-15 of the segment are not zero\n");
+return -EINVAL;
+}
+
+if ( reg.sel == 0 && reg.base == 0 && reg.limit == 0 &&
+ reg.attr.bytes == 0)
+{
+if ( seg == x86_seg_cs || seg == x86_seg_ss )
+{
+gprintk(XENLOG_ERR, "Null selector provided for CS or SS\n");
+return -EINVAL;
+}
+return 0;
+}
+
+if ( reg.attr.fields.p != 1 )
+{
+gprintk(XENLOG_ERR, "Non-present segment provided\n");
+return -EINVAL;
+}
+
+if ( seg == x86_seg_cs && !(reg.attr.fields.type & 0x8) )
+{
+gprintk(XENLOG_ERR, "CS is missing code type\n");
+return -EINVAL;
+}
+
+if ( seg != x86_seg_cs && !!(reg.attr.fields.type & 0x8) )
+{
+gprintk(XENLOG_ERR, "Non code segment with code type set\n");
+return -EINVAL;
+}
+
+
[Xen-devel] [PATCH v8 18/21] libxc/xen: introduce a start info structure for HVMlite guests
This structure contains the physical address of the command line, as well as
the physical address of the list of loaded modules. The physical address of
this structure is passed to the guest at boot time in the %ebx register.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v7:
- Add a comment to clarify that nothing will be loaded at physical address
0.
- Add Andrew Cooper Reviewed-by.
- Add Wei Liu Ack.
Changes since v6:
- Add a check to make sure the start info data is placed below 4GB.
- Make sure byte addresses are treated as uintptr_t.
- Fix single-line comment.
Changes since v5:
- Change some of the calculations performed to get the total size of the
start_info region.
- Replace the mention of HVMlite in a comment with PVH.
- Don't use 64bit integers in hvm_modlist_entry.
---
tools/libxc/xc_dom_x86.c | 68 +++-
xen/include/public/xen.h | 23
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 63b4832..7cf2a17 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -561,7 +561,70 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
special_pfn(SPECIALPAGE_SHARING));
-if ( dom->device_model )
+if ( !dom->device_model )
+{
+struct xc_dom_seg seg;
+struct hvm_start_info *start_info;
+char *cmdline;
+struct hvm_modlist_entry *modlist;
+void *start_page;
+size_t cmdline_size = 0;
+size_t start_info_size = sizeof(*start_info);
+
+if ( dom->cmdline )
+{
+cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
+start_info_size += cmdline_size;
+
+}
+if ( dom->ramdisk_blob )
+start_info_size += sizeof(*modlist); /* Limited to one module. */
+
+rc = xc_dom_alloc_segment(dom, &seg, "HVMlite start info", 0,
+ start_info_size);
+if ( rc != 0 )
+{
+DOMPRINTF("Unable to reserve memory for the start info");
+goto out;
+}
+
+start_page = xc_map_foreign_range(xch, domid, start_info_size,
+ PROT_READ | PROT_WRITE,
+ seg.pfn);
+if ( start_page == NULL )
+{
+DOMPRINTF("Unable to map HVM start info page");
+goto error_out;
+}
+
+start_info = start_page;
+cmdline = start_page + sizeof(*start_info);
+modlist = start_page + sizeof(*start_info) + cmdline_size;
+
+if ( dom->cmdline )
+{
+strncpy(cmdline, dom->cmdline, MAX_GUEST_CMDLINE);
+cmdline[MAX_GUEST_CMDLINE - 1] = '\0';
+start_info->cmdline_paddr = (seg.pfn << PAGE_SHIFT) +
+((uintptr_t)cmdline - (uintptr_t)start_info);
+}
+
+if ( dom->ramdisk_blob )
+{
+modlist[0].paddr = dom->ramdisk_seg.vstart - dom->parms.virt_base;
+modlist[0].size = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+start_info->modlist_paddr = (seg.pfn << PAGE_SHIFT) +
+((uintptr_t)modlist - (uintptr_t)start_info);
+start_info->nr_modules = 1;
+}
+
+start_info->magic = HVM_START_MAGIC_VALUE;
+
+munmap(start_page, start_info_size);
+
+dom->start_info_pfn = seg.pfn;
+}
+else
{
/*
* Allocate and clear additional ioreq server pages. The default
@@ -953,6 +1016,9 @@ static int vcpu_hvm(struct xc_dom_image *dom)
/* Set the IP. */
bsp_ctx.cpu.rip = dom->parms.phys_entry;
+if ( dom->start_info_pfn )
+bsp_ctx.cpu.rbx = dom->start_info_pfn << PAGE_SHIFT;
+
/* Set the end descriptor. */
bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
bsp_ctx.end_d.instance = 0;
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index ff5547e..5486da3 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -784,6 +784,29 @@ struct start_info {
};
typedef struct start_info start_info_t;
+/*
+ * Start of day structure passed to PVH guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so
+ * a 0 value in any of this fields should be treated as
+ * not present.
+ */
+struct hvm_start_info {
+#define HVM_START_MAGIC_VALUE 0x336ec578
+uint32_t magic; /* Contains the magic value 0x336ec578 */
+/* ("xEn3" with the 0x80 bit of the "E" set).*/
+uint32_t flags; /* SIF_xxx flags.*/
+uint32_t cmdline_paddr; /* Ph
Re: [Xen-devel] [PATCH v8 02/21] xen/vlapic: fixes for HVM code when running without a vlapic
On 06/11/15 16:05, Roger Pau Monne wrote: > The HVM related code (SVM, VMX) generally assumed that a local apic is > always present. With the introduction of a HVM mode were the local apic can > be removed, some of this broken code paths arised. > > The SVM exit/resume paths unconditionally checked the state of the lapic, > which is wrong if it's been disabled by hardware, fix this by adding the > necessary checks. On the VMX side, make sure we don't add mappings for a > local apic if it's disabled. > > In the generic vlapic code, add checks to prevent setting the TSC deadline > timer if the lapic is disabled, and also prevent trying to inject interrupts > from the PIC is the lapic is also disabled. > > Signed-off-by: Roger Pau Monné > Reviewed-by: Boris Ostrovsky > Cc: Boris Ostrovsky > Cc: Suravee Suthikulpanit > Cc: Aravind Gopalakrishnan > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Jun Nakajima > Cc: Eddie Dong > Cc: Kevin Tian Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 63720: tolerable all pass - PUSHED
flight 63720 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63720/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
baseline version:
xen 6f04de658574833688c3f9eab310e7834d56a9c0
Last test of basis63624 2015-11-04 18:01:19 Z1 days
Testing same since63720 2015-11-06 15:01:02 Z0 days1 attempts
People who touched revisions under test:
Dario Faggioli
Jan Beulich
Paul Durrant
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
+ branch=xen-unstable-smoke
+ revision=22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'g
[Xen-devel] [PATCH 1/4] docs: Document control features the can be advertised by guests...
...via xenstore.
XenServer already makes use of ~/control/feature-suspend being written
to advertise guest capability of responding to 'suspend' when written to
~/control/shutdown and, since they are derived from XenServer drivers,
the Xen Project Windows PV drivers attempt to write this value. The write
currently fails for libxl provisioned VMs because ~/control is read-only
to the guest (only ~/control/shutdown is writable, for ackowledgement
purposes).
This patch documents feature-suspend and also a set of similar control
feature flags, so that that they may be added to libxl provisioned
guests by subsequent patches:
feature-halt: PV drivers/agent can halt the guest
feature-reboot: PV drivers/agent can reboot the guest
feature-s3: PV drivers/agent can trigger guest sleep (HVM only)
feature-s4: PV drivers/agent can trigger guest hibernate (HVM only)
The patch (bacause it adds features relating to S3 and S4 power states)
also clarifies that the initial set of platform properties mentioned are
booleans, and updates the specifier accordingly.
Signed-off-by: Paul Durrant
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
docs/misc/xenstore-paths.markdown | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index d94ea9d..ec3cc5f 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -178,9 +178,9 @@ will not relocate guest memory.
The BIOS used by this domain.
- ~/platform/* [HVM,INTERNAL]
+ ~/platform/* = ("0"|"1") [HVM,INTERNAL]
-Various platform properties.
+Various boolean platform properties.
* acpi -- is ACPI enabled for this domain
* acpi_s3 -- is ACPI S3 support enabled for this domain
@@ -321,12 +321,44 @@ by udev ("0") or will be run by the toolstack directly
("1").
~/control/shutdown = (""|COMMAND) [w]
This is the PV shutdown control node. A toolstack can write various
-commands here to cause various guest shutdown, reboot or suspend
+commands here to cause various guest halt, reboot or suspend
activities. The guest acknowledges a request by writing the empty
string back to the command node.
The precise protocol is not yet documented.
+ ~/control/feature-halt = (""|"0"|"1") [w]
+
+This is initialized to "" by the toolstack but may be set to 0 or 1 by
+a guest to indicate that it is capable or incapable, respectively, of
+halting if 'halt' is written to ~/control/shutdown.
+
+ ~/control/feature-reboot = (""|"0"|"1") [w]
+
+This is initialized to "" by the toolstack but may be set to 0 or 1 by
+a guest to indicate that it is capable or incapable, respectively, of
+rebooting if 'reboot' is written to ~/control/shutdown.
+
+ ~/control/feature-suspend = (""|"0"|"1") [w]
+
+This is initialized to "" by the toolstack but may be set to 0 or 1 by
+a guest to indicate that it is capable or incapable, respectively, of
+suspending if 'suspend' is written to ~/control/shutdown.
+
+ ~/control/feature-s3 = (""|"0"|"1") [w,HVM]
+
+This is initialized to "" by the toolstack but may be set to 0 or 1 by
+a guest to indicate that it is capable or incapable, respectively, of
+triggering a guest sleep if 's3' is written to ~/control/shutdown and
+~/platform/acpi_s3 is 1.
+
+ ~/control/feature-s4 = (""|"0"|"1") [w,HVM]
+
+This is initialized to "" by the toolstack but may be set to 0 or 1 by
+a guest to indicate that it is capable or incapable, respectively, of
+triggering a guest hibernate if 's4' is written to ~/control/shutdown
+and ~/platform/acpi_s4 is 1.
+
~/control/platform-feature-multiprocessor-suspend = (0|1) []
Indicates to the guest that this platform supports the multiprocessor
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Critique of the Xen Security Process
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Recently Xen has released the XSA-148 advisory [1] addressing a fatal bug in the
hypervisor. The bug has been lurking there for the last 7 years! We, the Qubes
OS Project, have commented on this in our Security Bulletin #22 [2]. And far
from enthusiastic commentary that was (FWIW, it was me who wrote this QSB, as
evidenced in the commits log, in case some from the Xen community would like to
direct their rage towards a particular human being ;) Ian Jackson then wrote a
response on the Xen blog [3]. I was then asked to share some more thoughts about
how I thought Xen could actually improve its security process [4]. So, I share
some these below:
1. First of all, I wish Xen was somehow more defensively coded. To provide some
examples:
a. In XSA-109 [5] there was a problem with the hypervisor dereferencing a NULL
pointer. The problem was fixed by the Xen Security Team by applying a patch
which (hopefully) made sure the execution path that lead to this NULL pointer
dereferencing code was never taken. Back then I suggested (on the Xen
pre-disclosure list) to make this patch more explicit though:
> On Wed, Jan 21, 2015 at 02:31:51PM +0100, Joanna Rutkowska wrote:
>
> (...)
>>
>>
>> Wouldn't it be prudent to also check if:
>>
>>
>>
>> (v->arch.paging.mode>{write_guest_entry,cmpxchg_guest_entry} != NULL)
>>
>>
>>
>> ... in the two affected functions, just before derefing these function
>>
>> pointers?
>>
>>
>>
>> Going even a step further: how about replacing all
>>
>> function-pointer-based calls with macros that first validates the
>>
>> pointer before derefing it? At least when the system doesn't have SMEP?
>>
>>
>>
...to which I got a reply from one of the Xen Security Team engineers that the
above might perhaps be justified in debug builds only, followed by a standard:
"feel free to contribute a patch".
b. The XSA-123 [6] was another critical security bug in Xen, this time resulting
from one of the hypervisor developer's fetish to use an absolutely confusing
construct in order to save a few modest bytes in a structure which might have
been allocated by the system maybe a few tens of times at best. Even more
worrying was the way how Xen Security Team decided to fix the bug: again by
modifying some condition in the code further up the execution path, with the
hopes that this time they would ensure this puzzling construct would always be
used properly. We wrote more about this in our QSB #18 [7].
c. Finally, the way how Xen fixed the recent XSA-148 looks also very reactive,
IMHO. With a bug of this calibre, I would expect Xen to carefully review and
augment all its PV memory virtualization code with additional checks (ASSERTs),
ensuring certain invariants are always satisfied. Such as e.g. that none of the
pages containing PDEs or PTEs are becoming writeable by the VM.
I can't help but have a feeling that some of the Xen developers seem to be
overconfident in their belief they can fully understand all the possible
execution paths in their code. Well, the XSAs quoted above are an indisputable
prove that this is not quite always the case. Realizing that, each developer by
themselves, might be a great step towards a more secure hypervisor...
2. Another security-related aspect of the Xen project is how it totally ignores
problems related to the build process security. Those who don't believe me
should grep the sources for wget, which is now disguised as "FETCHER" shell
variable... (so grep for "FETCHER" string)
I feel embarrassed that I need to explain, at the end of 2015, why the build
process of any serious software project should not blindly download unsigned
components (sources) from the Internet, especially if it is about to execute
Makefiles from these components a moment later... Come on, guys!
(Of course we have been forced to get around this gapping security whole in
Qubes OS [8] ourselves, sadly with a method that is not well suited for
upstreaming).
3. Another thing is, of course: stop adding features to the core hypervisor. We
really need Xen to finally mature, stabilize, and for its development process to
be slowing down over time (just the bug fixes). We need a long-term-supported
hypervisor, which doesn't change with subsonic speed. This would allow this core
code to be widely audited by many experts. If some users want features, these
shoul
[Xen-devel] [PATCH 0/4] docs: Document xenstore paths
Patch #1 documents paths, some already in used by XenServer, which can be used by guests to advertise contol capabilities. Patch #2 documents paths which can be used to advertise PV driver versions. Patch #3 documents paths which can be used by guests to advertise hotplug capabilities. Patch #4 documents paths which can be used by guests to advertise network addresses. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/4] docs: Document xenstore paths for domain network address information
It is useful to be able to see the network addresses in use by a domain for a particular vif in xenstore, for example so that ssh can be invoked by a toolstack to log into the guest domain. This patch documents paths to allow a domain to advertise MAC (unicast and multicast) and IP (versions 4 and 6) address information. Signed-off-by: Paul Durrant Cc: Ian Campbell Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- docs/misc/xenstore-paths.markdown | 29 + 1 file changed, 29 insertions(+) diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown index 9e98d6f..68d3dbf 100644 --- a/docs/misc/xenstore-paths.markdown +++ b/docs/misc/xenstore-paths.markdown @@ -39,6 +39,8 @@ before regexp expansion: * $UUID -- a UUID in the form ---- * $NAME -- a string identifying an object within a domain. Typically comprising only alphanumeric characters. +* $INDEX -- an integer used as part of a path when listing a set of +values. Typically these integers are contiguous. VALUES are strings and can take the following forms: @@ -56,6 +58,13 @@ VALUES are strings and can take the following forms: * VERSION -- 2 or 3 integers, in decimal form separated by ".", specifying major version, minor version, and then (optionally) micro version. +* MAC_ADDRESS -- 6 integers, in hexadecimal form, separated by ':', + specifying an ethernet MAC address. +* IPV4_ADDRESS -- 4 integers, in decimal form, separated by '.', + specifying an IP version 4 address. +* IPV6_ADDRESS -- 8 integers, in hexadecimal form, separated by ':', + specifying an IP version 6 address. (There should + be strictly 8 integers i.e. '::' compression). Additional TAGS may follow as a comma separated set of the following tags enclosed in square brackets. @@ -399,6 +408,26 @@ An HVM domain can indicate to a toolstack that it is capable of responding to instantiation of a new vbd by bringing online a new PV block device without the need for a reboot. + ~/attr/vif/$DEVID/name = STRING [w] + +A domain may write its internal 'friendly' name for a network device +using this path. + + ~/attr/vif/$DEVID/mac/$INDEX = MAC_ADDRESS [w] + +A domain may write the set of MAC addresses (unicast and multicast) +in use by the network frontend using paths of this form. + + ~/attr/vif/$DEVID/ipv4/$INDEX = IPV4_ADDRESS [w] + +A domain may write the set of IP version 4 addresses in use by the +stack bound to the network frontend using paths of this form. + + ~/attr/vif/$DEVID/ipv6/$INDEX = IPV6_ADDRESS [w] + +A domain may write the set of IP version 6 addresses in use by the +stack bound to the network frontend using paths of this form. + ### Paths private to the toolstack ~/device-model/$DOMID/state [w] -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] docs: Document a path for PV driver version information...
...to be advertised by a guest.
For domain management purposes it is convenient to be able to see
PV driver version information in xenstore. The XAPI toolstack in
XenServer has always created a ~/drivers path for this purpose.
This patch documents that path and also adds a specification of how
it should be used.
Signed-off-by: Paul Durrant
---
docs/misc/xenstore-paths.markdown | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index ec3cc5f..7701632 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -37,6 +37,8 @@ before regexp expansion:
the "other" domain. i.e. ~ refers to the domain providing a service
while $DOMID is the consumer of that service.
* $UUID -- a UUID in the form ----
+* $NAME -- a string identifying an object within a domain. Typically
+ comprising only alphanumeric characters.
VALUES are strings and can take the following forms:
@@ -51,6 +53,9 @@ VALUES are strings and can take the following forms:
* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
separated by a "|" and all the alternatives are enclosed in "(" and
")".
+* VERSION -- 2 or 3 integers, in decimal form separated by ".",
+ specifying major version, minor version, and then
+(optionally) micro version.
Additional TAGS may follow as a comma separated set of the following
tags enclosed in square brackets.
@@ -377,6 +382,11 @@ protocol definition.
A domain writable path. Available for arbitrary domain use.
+ ~/drivers/$NAME/version = VERSION [w]
+
+A domain may write version information for PV driver $NAME using
+this path.
+
### Paths private to the toolstack
~/device-model/$DOMID/state [w]
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] docs: Document a xenstore path for PV driver version information...
...to be advertised by a guest.
For domain management purposes it is convenient to be able to see
PV driver version information in xenstore. The XAPI toolstack in
XenServer has always created a ~/drivers path for this purpose.
This patch documents that path and also adds a specification of how
it should be used.
Signed-off-by: Paul Durrant
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
docs/misc/xenstore-paths.markdown | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index ec3cc5f..7701632 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -37,6 +37,8 @@ before regexp expansion:
the "other" domain. i.e. ~ refers to the domain providing a service
while $DOMID is the consumer of that service.
* $UUID -- a UUID in the form ----
+* $NAME -- a string identifying an object within a domain. Typically
+ comprising only alphanumeric characters.
VALUES are strings and can take the following forms:
@@ -51,6 +53,9 @@ VALUES are strings and can take the following forms:
* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
separated by a "|" and all the alternatives are enclosed in "(" and
")".
+* VERSION -- 2 or 3 integers, in decimal form separated by ".",
+ specifying major version, minor version, and then
+(optionally) micro version.
Additional TAGS may follow as a comma separated set of the following
tags enclosed in square brackets.
@@ -377,6 +382,11 @@ protocol definition.
A domain writable path. Available for arbitrary domain use.
+ ~/drivers/$NAME/version = VERSION [w]
+
+A domain may write version information for PV driver $NAME using
+this path.
+
### Paths private to the toolstack
~/device-model/$DOMID/state [w]
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features
Without some indication from an HVM domain it is not possible for a
toolstack to know whether instantiation of a new vbd or vif should
result in a new PV device of the appropriate type being instantiated
in a guest. (In other words whether PV drivers are present and
functioning).
This patch document two paths which vif and vbd frontend drivers can
use to advertise their ability to respond to new vif or vbd
instantiations.
Signed-off-by: Paul Durrant
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
docs/misc/xenstore-paths.markdown | 12
1 file changed, 12 insertions(+)
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index 7701632..9e98d6f 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -387,6 +387,18 @@ A domain writable path. Available for arbitrary domain use.
A domain may write version information for PV driver $NAME using
this path.
+ ~/feature/hotplug/vif = ("0"|"1") [w,HVM]
+
+An HVM domain can indicate to a toolstack that it is capable
+of responding to instantiation of a new vif by bringing online a
+new PV network device without the need for a reboot.
+
+ ~/feature/hotplug/vbd = ("0"|"1") [w,HVM]
+
+An HVM domain can indicate to a toolstack that it is capable
+of responding to instantiation of a new vbd by bringing online a
+new PV block device without the need for a reboot.
+
### Paths private to the toolstack
~/device-model/$DOMID/state [w]
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 3/3] iommu: add rmrr Xen command line option for extra rmrrs
On Fri, Nov 06, 2015 at 04:05:25AM -0700, Jan Beulich wrote:
> >>> On 06.11.15 at 05:22, wrote:
> > On Wed, Oct 28, 2015 at 10:05:31AM -0600, Jan Beulich wrote:
> >> >>> On 27.10.15 at 21:36, wrote:
> >> > +static void __init add_extra_rmrr(void)
> >> > +{
> >> > +struct acpi_rmrr_unit *acpi_rmrr;
> >> > +struct acpi_rmrr_unit *rmrru;
> >> > +unsigned int dev, seg, i;
> >> > +unsigned long pfn;
> >> > +bool_t overlap;
> >> > +
> >> > +for ( i = 0; i < nr_rmrr; i++ )
> >> > +{
> >> > +if ( extra_rmrr_units[i].base_pfn > extra_rmrr_units[i].end_pfn
> >> > )
> >> > +{
> >> > +printk(XENLOG_ERR VTDPREFIX
> >> > + "Invalid RMRR Range "ERMRRU_FMT"\n",
> >> > + ERMRRU_ARG(extra_rmrr_units[i]));
> >> > +continue;
> >> > +}
> >> > +
> >> > +if ( extra_rmrr_units[i].end_pfn - extra_rmrr_units[i].base_pfn
> >> > >=
> >> > + MAX_EXTRA_RMRR_PAGES )
> >> > +{
> >> > +printk(XENLOG_ERR VTDPREFIX
> >> > + "RMRR range "ERMRRU_FMT" exceeds
> >> > "__stringify(MAX_EXTRA_RMRR_PAGES)" pages\n",
> >> > + ERMRRU_ARG(extra_rmrr_units[i]));
> >> > +continue;
> >> > +}
> >> > +
> >> > +overlap = 0;
> >> > +list_for_each_entry(rmrru, &acpi_rmrr_units, list)
> >> > +{
> >> > +if ( pfn_to_paddr(extra_rmrr_units[i].base_pfn) <
> >> > rmrru->end_address &&
> >> > + rmrru->base_address <
> >> > pfn_to_paddr(extra_rmrr_units[i].end_pfn + 1) )
> >>
> >> Aren't both ranges inclusive? I.e. shouldn't the first one be <= (and
> >> the second one could be <= too when dropping the +1), matching
> >> the check acpi_parse_one_rmrr() does?
> >
> > The end_address is not inclusive, while the start_address is.
> > These to from rmrr_identity_mapping()
> > ...
> > ASSERT(rmrr->base_address < rmrr->end_address);
> >
>
> These are byte-granular addresses.
>
> > and:
> > ...
> > while ( base_pfn < end_pfn )
> > {
> > int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
> >
> >
> >
> > if ( err )
> >
> >
> > return err;
> >
> >
> > base_pfn++;
> >
> >
> > }
> > ...
> >
> > I think this condition should not be a problem. But yes, its not uniform
> > with acpi_parse_one_rmrr.
>
> Did you actually pay attention to how end_pfn gets calculated?
>
> > I guess I should send another version then?
>
> Yes of course.
Ok, I see your point.
>
> >> > +}
> >> > +if ( seg != PCI_SEG(extra_rmrr_units[i].sbdf[0]) )
> >> > +{
> >> > +printk(XENLOG_ERR VTDPREFIX
> >> > + "Segments are not equal for RMRR range
> >> > "ERMRRU_FMT"\n",
> >> > + ERMRRU_ARG(extra_rmrr_units[i]));
> >> > +scope_devices_free(&acpi_rmrr->scope);
> >> > +xfree(acpi_rmrr);
> >> > +continue;
> >> > +}
> >> > +
> >> > +acpi_rmrr->segment = seg;
> >> > +acpi_rmrr->base_address =
> > pfn_to_paddr(extra_rmrr_units[i].base_pfn);
> >> > +acpi_rmrr->end_address =
> >> > pfn_to_paddr(extra_rmrr_units[i].end_pfn +
> > 1);
> >>
> >> And this seems wrong too, unless I'm mistaken with the inclusive-ness.
> >>
> > The end_address is exclusive, see above.
> No - see above.
You are right, I actually meant to say end_pfn for extra rmrr in not inclusive.
And this case is only valid when base_pfn == end_pfn as the parser does
not take care of the case where there is only one pfn specified. The
assumption in this case is that user meant [base_pfn, base_pfn + 1].
I think it will be safe to add the condition when incrementing.
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/4] docs: Document a path for PV driver version information...
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 06 November 2015 17:22
> To: xen-de...@lists.xenproject.org
> Cc: Paul Durrant
> Subject: [PATCH 2/4] docs: Document a path for PV driver version
> information...
>
> ...to be advertised by a guest.
>
> For domain management purposes it is convenient to be able to see
> PV driver version information in xenstore. The XAPI toolstack in
> XenServer has always created a ~/drivers path for this purpose.
>
> This patch documents that path and also adds a specification of how
> it should be used.
>
> Signed-off-by: Paul Durrant
Sorry, this one is stale. It should not have been sent... Sorry for the noise.
Paul
> ---
> docs/misc/xenstore-paths.markdown | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-
> paths.markdown
> index ec3cc5f..7701632 100644
> --- a/docs/misc/xenstore-paths.markdown
> +++ b/docs/misc/xenstore-paths.markdown
> @@ -37,6 +37,8 @@ before regexp expansion:
>the "other" domain. i.e. ~ refers to the domain providing a service
>while $DOMID is the consumer of that service.
> * $UUID -- a UUID in the form ----
> +* $NAME -- a string identifying an object within a domain. Typically
> + comprising only alphanumeric characters.
>
> VALUES are strings and can take the following forms:
>
> @@ -51,6 +53,9 @@ VALUES are strings and can take the following forms:
> * (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
>separated by a "|" and all the alternatives are enclosed in "(" and
>")".
> +* VERSION -- 2 or 3 integers, in decimal form separated by ".",
> + specifying major version, minor version, and then
> + (optionally) micro version.
>
> Additional TAGS may follow as a comma separated set of the following
> tags enclosed in square brackets.
> @@ -377,6 +382,11 @@ protocol definition.
>
> A domain writable path. Available for arbitrary domain use.
>
> + ~/drivers/$NAME/version = VERSION [w]
> +
> +A domain may write version information for PV driver $NAME using
> +this path.
> +
> ### Paths private to the toolstack
>
> ~/device-model/$DOMID/state [w]
> --
> 2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH] Feature doc: Added Feature Maturity Lifecycle
- Incorporated feedback from http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html Open Issues: - Did not build and test the doc yet (want to get the content right first) - Decide on supported status in MAINTAINER file - Resolve loose ends on where and how to record Feature State Signed-off-by: Lars Kurth --- docs/features/feature-maturity-lifecycle.pandoc | 260 1 file changed, 260 insertions(+) create mode 100644 docs/features/feature-maturity-lifecycle.pandoc diff --git a/docs/features/feature-maturity-lifecycle.pandoc b/docs/features/feature-maturity-lifecycle.pandoc new file mode 100644 index 000..46f98a7 --- /dev/null +++ b/docs/features/feature-maturity-lifecycle.pandoc @@ -0,0 +1,260 @@ +% Feature Maturity Lifecycle +% Revision 1 + +\clearpage + +# Basics +--- --- +Status: **Proposal** + + Component: Development Process +--- --- + +# Purpose and Scope + +The purpose of this document is to define the possible states a feature. +**Features** may be one of the following: +* End user Feature: aka a pice of functionality that is controllable + by users of Xen through a command line option exposed via xl or + libvirt, a config file or otherwise +* Support for a Hardware platform: e.g. x86 or ARM +* Support for a specific Hardware platforms, e.g. Thunder X, + Xilinx ZynqMP, etc. +* A set of APIs, e.g. mem-event API, memory sharing APIs, etc. + +It is also the intent, that this document is used to set expectations +of contributors to the Xen Project hypervisor, such that they can take +appropriate steps to ensure that eventually a feature that they develop +is a supported by the community. + +Further, it will help users of the Xen Project hypervisors understand +how developers use the feature states. This will help users make informed +decisions about the risk involved in using a feature. + +# Dependencies + +This document refers to definitions in other files and project conventions, +in particular: + +## Status of subsystems in the MAINTAINERS file +The [MAINTAINERS] +(http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=MAINTAINERS;hb=HEAD) +file maps individuals against groups of files in the source tree. In +the context of this document, we say that a feature is **maintained**, +iff all components of that feature are marked as one of the following +* **Supported**: Someone is actually paid to look after the code. +* **Maintained**: Someone actually looks after the code. + +## Classification of public APIs and interfaces: +APIs and other interfaces are declared stable by agreement +on the xen-devel@ mailing list. We consider a feature as +**stable**, iff all public APIs and interfaces a feature depends +on have been declared stable. + +## Testing +The Xen Project runs a continuous test and integration system +in the project's test lab. We consider a **feature tested**, iff +one of the following two criteria holds: +* The feature is tested automatically +* At least once during each release freeze, the feature's + maintainers produce a test report (by a deadline specified by + the release manager). Features with no test report get + downgraded from **Supported** to some lower status. + +For hardware platforms we consider a **platform tested**, iff +* Appropriate hardware for said platform is live and in active use + in our test lab and tests consistently pass against that platform. +* At least once during each release freeze, the hardware platform's + maintainers produce a test report (by a deadline specified by + the release manager). Hardware Platforms with no test report get + downgraded from **Supported** to some lower status. + +## Documentation +The Xen Project requires that documentation for user facing +features and in-code API documentation (or user guides as +appropriate) are provided in tree. + +For new larger features, we do also expect that feature documentation +is submitted to [xen.git / docs / features] +(http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=docs/features;hb=HEAD). +Whether such documentation is required depends on the discretion of +the maintainers and committers that review new features. + +We say that a feature as **documented**, if relevant documentation has +been committed to the tree. + +# State Definitions + +This section lists state definitions of a **Feature** in terms of +properties. This section talks about Features, for readability, but +is used interchangeably between **Features** and **Platforms**. + +States are listed in order of increasing number +of properties. Note that note all features will require to go +through each state: for example small and non-risky features +may go straight from under development to supported. It is up to +the development community to judge and discuss, which states +are necessary based on the size and risk of a feature. + +## Preview +* Partially completed, with missing functionality +* May **not be f
[Xen-devel] [RFC PATCHv1 0/3]: x86/ept: reduce translation invalidation impact
This RFC series improves the performance of EPT by reducing the impact of the translation invalidations (ept_sync_domain()). Two approaches are used: a) Removing unnecessary invalidations after fixing misconfigured entries (after a type change). b) Deferring invalidations until the p2m write lock is released. Prior to this change a 16 VCPU guest could not be successfully migrated on an (admittedly slow) 160 PCPU box because the p2m write lock was held for such extended periods of time. This starved the read lock needed (by the toolstack) to map the domain's memory, triggering the watchdog. After this change a 64 VCPU guest could be successfully migrated. ept_sync_domain() is very expensive because: a) it uses on_selected_cpus() and the IPI cost can be particularly high for a multi-socket machine. b) on_selected_cpus() is serialized by its own spin lock. On this particular box, ept_sync_domain() could take ~3-5 ms. Simply using a fair rw lock was not sufficient to resolve this (but it was an improvement) as the cost of the ept_sync_domain calls() was still delaying the read locks enough for the watchdog to trigger (the toolstack maps a batch of 1024 GFNs at a time, which means trying to acquire the p2m read lock 1024 times). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1 2/3] mm: don't free pages until mm locks are released
If a page is freed without translations being invalidated, and the page is
subsequently allocated to another domain, a guest with a cached
translation will still be able to access the page.
Currently translations are invalidated before releasing the page ref, but
while still holding the mm locks. To allow translations to be invalidated
without holding the mm locks, we need to keep a reference to the page
for a bit longer in some cases.
[ This seems difficult to a) verify as correct; and b) difficult to get
correct in the future. A better suggestion would be useful. Perhaps
using something like pg->tlbflush_needed mechanism that already exists
for pages from PV guests? ]
Signed-off-by: David Vrabel
---
xen/arch/x86/mm/p2m.c | 4
xen/common/memory.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index ed0bbd7..e13672d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2758,6 +2758,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long
fgfn,
p2m_type_t p2mt, p2mt_prev;
unsigned long prev_mfn, mfn;
struct page_info *page;
+struct page_info *prev_page = NULL;
int rc;
struct domain *fdom;
@@ -2805,6 +2806,9 @@ int p2m_add_foreign(struct domain *tdom, unsigned long
fgfn,
prev_mfn = mfn_x(get_gfn(tdom, gpfn, &p2mt_prev));
if ( mfn_valid(_mfn(prev_mfn)) )
{
+prev_page = mfn_to_page(_mfn(prev_mfn));
+get_page(prev_page, tdom);
+
if ( is_xen_heap_mfn(prev_mfn) )
/* Xen heap frames are simply unhooked from this phys slot */
guest_physmap_remove_page(tdom, gpfn, prev_mfn, 0);
diff --git a/xen/common/memory.c b/xen/common/memory.c
index a3bffb7..571c754 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -272,8 +272,8 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
guest_physmap_remove_page(d, gmfn, mfn, 0);
-put_page(page);
put_gfn(d, gmfn);
+put_page(page);
return 1;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1 1/3] x86/ept: remove unnecessary sync after resolving misconfigured entries
When using EPT, type changes are done with the following steps:
1. Set entry as invalid (misconfigured) by settings a reserved memory
type.
2. Flush all EPT and combined translations (ept_sync_domain()).
3. Fixup misconfigured entries as required (on EPT_MISCONFIG vmexits or
when explicitly setting an entry.
Since resolve_misconfig() only updates entries that were misconfigured,
there is no need to invalidate any translations since the hardware
does not cache misconfigured translations (vol 3, section 28.3.2).
Remove the unnecessary (and very expensive) ept_sync_domain() calls).
Signed-off-by: David Vrabel
---
xen/arch/x86/mm/p2m-ept.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 86440fc..a41d7d2 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -644,7 +644,6 @@ bool_t ept_handle_misconfig(uint64_t gpa)
spurious = curr->arch.hvm_vmx.ept_spurious_misconfig;
rc = resolve_misconfig(p2m, PFN_DOWN(gpa));
curr->arch.hvm_vmx.ept_spurious_misconfig = 0;
-ept_sync_domain(p2m);
p2m_unlock(p2m);
@@ -692,12 +691,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn,
mfn_t mfn,
/* Carry out any eventually pending earlier changes first. */
ret = resolve_misconfig(p2m, gfn);
if ( ret < 0 )
-{
-ept_sync_domain(p2m);
return ret;
-}
-if ( ret > 0 )
-needs_sync = sync_on;
ASSERT((target == 2 && hap_has_1gb) ||
(target == 1 && hap_has_2mb) ||
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1 3/3] x86/ept: defer the invalidation until the p2m lock is released
Holding the p2m lock while calling ept_sync_domain() is very expensive
since it does a on_selected_cpus() call. IPIs on many socket machines
can be very slows and on_selected_cpus() is serialized.
Defer the invalidate until the p2m lock is released. Since the processor
may cache partial translations, we also need to make sure any page table
pages to be freed are not freed until the invalidate is complete. Such
pages are temporarily stored an per-PCPU list.
Signed-off-by: David Vrabel
---
xen/arch/x86/mm/mm-locks.h | 23 +++
xen/arch/x86/mm/p2m-ept.c | 17 -
xen/arch/x86/mm/p2m.c | 37 +++--
xen/include/asm-x86/p2m.h | 6 ++
4 files changed, 72 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 76c7217..473aaab 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -263,14 +263,21 @@ declare_mm_lock(altp2mlist)
*/
declare_mm_rwlock(altp2m);
-#define p2m_lock(p) \
-{ \
-if ( p2m_is_altp2m(p) ) \
-mm_write_lock(altp2m, &(p)->lock); \
-else\
-mm_write_lock(p2m, &(p)->lock); \
-}
-#define p2m_unlock(p) mm_write_unlock(&(p)->lock);
+#define p2m_lock(p) \
+do {\
+if ( p2m_is_altp2m(p) ) \
+mm_write_lock(altp2m, &(p)->lock); \
+else\
+mm_write_lock(p2m, &(p)->lock); \
+(p)->defer_flush++; \
+} while (0)
+#define p2m_unlock(p) \
+do {\
+bool_t need_flush = --(p)->defer_flush == 0 && (p)->need_flush; \
+mm_write_unlock(&(p)->lock);\
+if (need_flush && (p)->flush) \
+(p)->flush(p); \
+} while (0)
#define gfn_lock(p,g,o) p2m_lock(p)
#define gfn_unlock(p,g,o) p2m_unlock(p)
#define p2m_read_lock(p) mm_read_lock(p2m, &(p)->lock)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index a41d7d2..a573c14 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -263,7 +263,7 @@ static void ept_free_entry(struct p2m_domain *p2m,
ept_entry_t *ept_entry, int l
unmap_domain_page(epte);
}
-p2m_free_ptp(p2m, mfn_to_page(ept_entry->mfn));
+p2m_free_ptp_defer(p2m, mfn_to_page(ept_entry->mfn));
}
static bool_t ept_split_super_page(struct p2m_domain *p2m,
@@ -1103,6 +1103,14 @@ void ept_sync_domain(struct p2m_domain *p2m)
if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
return;
+if ( p2m->defer_flush )
+{
+p2m->need_flush = 1;
+return;
+}
+else
+p2m->need_flush = 0;
+
ASSERT(local_irq_is_enabled());
if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
@@ -1121,6 +1129,12 @@ void ept_sync_domain(struct p2m_domain *p2m)
__ept_sync_domain, p2m, 1);
}
+static void ept_flush(struct p2m_domain *p2m)
+{
+ept_sync_domain(p2m);
+p2m_free_deferred_ptp(p2m);
+}
+
static void ept_enable_pml(struct p2m_domain *p2m)
{
/* Domain must have been paused */
@@ -1169,6 +1183,7 @@ int ept_p2m_init(struct p2m_domain *p2m)
p2m->change_entry_type_range = ept_change_entry_type_range;
p2m->memory_type_changed = ept_memory_type_changed;
p2m->audit_p2m = NULL;
+p2m->flush = ept_flush;
/* Set the memory type used when accessing EPT paging structures. */
ept->ept_mt = EPT_DEFAULT_MT;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e13672d..2ad1de4 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -504,6 +504,26 @@ void p2m_free_ptp(struct p2m_domain *p2m, struct page_info
*pg)
return;
}
+DEFINE_PER_CPU(struct page_list_head, p2m_deferred_free_pages);
+
+void p2m_free_ptp_defer(struct p2m_domain *p2m, struct page_info *pg)
+{
+page_list_del(pg, &p2m->pages);
+page_list_add(pg, &this_cpu(p2m_deferred_free_pages));
+}
+
+void p2m_free_deferred_ptp(struct p2m_domain *p2m)
+{
+struct page_list_head *list = &this_cpu(p2m_deferred_free_pages);
+struct page_info *pg, *tmp;
+
+page_list_for_each_safe(pg, tmp, list)
+{
+page_list_del(pg, list);
+p2m->domain->arch.paging.free_page(p2m->domain, pg);
+}
+}
+
/*
* Allocate a new p2m table for a domain.
*
@@ -2827,20 +2847,33 @@ int p2m_add_foreign(struct domain *tdom, unsigned long
fgfn,
"gpfn:%lx mfn:%lx fgfn:%lx td:%d fd:%d\n",
gpfn, mfn, fgfn, tdom->domain_id, fdom->domain_id);
-put_pag
Re: [Xen-devel] [PATCH 1/2] xen: move wallclock functions from x86 to common
On Thu, 5 Nov 2015, Jan Beulich wrote:
> >>> On 05.11.15 at 17:57, wrote:
> > --- a/xen/common/time.c
> > +++ b/xen/common/time.c
> > @@ -16,7 +16,13 @@
> > */
> >
> > #include
> > +#include
> > +#include
> > +#include
> > #include
> > +#include
> > +#include
> > +
> >
> > /* Nonzero if YEAR is a leap year (every 4 years,
>
> Stray blank line being added.
>
> Also please take the opportunity to remove xen/config.h here.
OK
> > @@ -85,3 +95,87 @@ struct tm gmtime(unsigned long t)
> >
> > return tbuf;
> > }
> > +
> > +/* Explicitly OR with 1 just in case version number gets out of sync. */
> > +#define version_update_begin(v) (((v)+1)|1)
> > +#define version_update_end(v) ((v)+1)
>
> This should be moved to a header instead of getting defined a second
> time here. Also please add spaces to match our coding style.
OK
> > +struct tm wallclock_time(uint64_t *ns)
> > +{
> > +uint64_t seconds, nsec;
> > +
> > +if ( !wc_sec )
> > +return (struct tm) { 0 };
> > +
> > +seconds = NOW() + SECONDS(wc_sec) + wc_nsec;
> > +nsec = do_div(seconds, 10);
> > +
> > +if ( ns )
> > +*ns = nsec;
> > +
> > +return gmtime(seconds);
> > +}
> > +
> > +
>
> Stray blank lines again.
OK
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 63676: regressions - FAIL
flight 63676 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 63369 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail blocked in 63369 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63369 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 63369 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 63369 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail 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-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: linuxb12403044336e7d567f309eb443aa9acf76380af baseline version: linux8341455f7f2b36212f8cdded7725e93b17f5a8fc Last test of basis63369 2015-10-29 22:43:54 Z7 days Testing same since63543 2015-11-03 18:11:46 Z2 days2 attempts People who touched revisions under test: Greg Kroah-Hartman Kosuke Tatsukawa Sasha Levin jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm
[Xen-devel] [libvirt test] 63702: regressions - FAIL
flight 63702 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/63702/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass version targeted for testing: libvirt 01db2479416df34609886cfcaea5e35e8e6c2fe7 baseline version: libvirt 3c7590e0a435d833895fc7b5be489e53e223ad95 Last test of basis63340 2015-10-28 04:19:47 Z9 days Failing since 63352 2015-10-29 04:20:29 Z8 days7 attempts Testing same since63702 2015-11-05 11:32:40 Z1 days1 attempts People who touched revisions under test: Daniel Veillard Jiri Denemark John Ferlan Laine Stump Luyao Huang Maxim Perevedentsev Michal Privoznik Michel Normand Roman Bogorodskiy jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt fail build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 344 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/4] docs: Document a xenstore path for PV driver version information...
On 06/11/15 17:21, Paul Durrant wrote:
> ...to be advertised by a guest.
>
> For domain management purposes it is convenient to be able to see
> PV driver version information in xenstore. The XAPI toolstack in
> XenServer has always created a ~/drivers path for this purpose.
>
> This patch documents that path and also adds a specification of how
> it should be used.
>
> Signed-off-by: Paul Durrant
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Keir Fraser
> Cc: Tim Deegan
> ---
> docs/misc/xenstore-paths.markdown | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/docs/misc/xenstore-paths.markdown
> b/docs/misc/xenstore-paths.markdown
> index ec3cc5f..7701632 100644
> --- a/docs/misc/xenstore-paths.markdown
> +++ b/docs/misc/xenstore-paths.markdown
> @@ -37,6 +37,8 @@ before regexp expansion:
>the "other" domain. i.e. ~ refers to the domain providing a service
>while $DOMID is the consumer of that service.
> * $UUID -- a UUID in the form ----
> +* $NAME -- a string identifying an object within a domain. Typically
> + comprising only alphanumeric characters.
>
> VALUES are strings and can take the following forms:
>
> @@ -51,6 +53,9 @@ VALUES are strings and can take the following forms:
> * (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
>separated by a "|" and all the alternatives are enclosed in "(" and
>")".
> +* VERSION -- 2 or 3 integers, in decimal form separated by ".",
> + specifying major version, minor version, and then
> + (optionally) micro version.
I am not sure version should come with a restriction like this. For
debug builds, it might be common to have a suffix. Furthermore, not all
software conforms to the $MAJOR.$MINOR.$MICRO scheme.
I would just leave it specified as a "string which identifies the
version of the driver", without any specific restrictions
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [BUG] Boot failures with mpt2sas / Intel RMS25JB080 module
Hi, [These lists are in the MAINTAINERS file for mpt2sas; I hope this is the correct place to report this problem. Xen-devel CCd as this is failing on trying to boot Xen] When booting Xen, mpt2sas finds my Intel RMS25JB080, but fails to load it correctly. This is a Debian jessie (stable) system, kernel version 3.16.0-4-amd64, Xen version 4.4.1. Relevant snippet of log output of failed boot: [ 64.095008] mpt2sas0: reply_post_free pool: pci_pool_alloc failed [ 64.535255] mpt2sas0: failure at /build/linux-xkTWug/linux-3.16.7-ckt11/drivers/scsi/mpt2sas/mpt2sas_scsih.c:8234/_scsih_probe()! ...it then fails to find any of my attached drives, so cannot boot, and I get dumped in the initramfs. Having googled a bit, I tried pci=realloc=off on the kernel command-line, as well as swiotlb=26422 ; neither of them changed the failure mode Booting bare-metal does work; relevant snippet of log output of successful (i.e. bare-metal) boot: [3.977037] mpt2sas0: diag reset: SUCCESS [4.178627] mpt2sas0: Allocated physical memory: size(17390 kB) [4.178630] mpt2sas0: Current Controller Queue Depth(7931), Max Controller Queue Depth(8192) [4.178631] mpt2sas0: Scatter Gather Elements per IO(128) [4.409752] mpt2sas0: LSISAS2308: FWVersion(20.00.02.00), ChipRevision(0x05), BiosVersion(07.39.00.00) [4.409755] mpt2sas0: Intel(R) Integrated RAID Module RMS25JB080 [4.409756] mpt2sas0: Protocol=(Initiator), Capabilities=(Raid,TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set Full,NCQ) [4.409846] mpt2sas0: sending port enable !! ... [5.941978] mpt2sas0: host_add: handle(0x0001), sas_addr(0x5001e67c17ff5000), phys(8) [5.980601] device-mapper: uevent: version 1.0.3 [5.980773] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-de...@redhat.com [ 11.823480] mpt2sas0: port enable: SUCCESS (and then it finds the attached disks) Fuller outputs: i) bare-metal boot dmesg: http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/bare_metal_dmesg ii) output from failed Xen boot (captured over a serial line with earlyprintk=xen and loglvl=all guest_loglvl=all): http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/failedboot-output-2 iii) kernel config (stock Debian): http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/config-3.16.0-4-amd64 iv) lspci -vvv output: http://www-uxsup.csx.cam.ac.uk/~mcv21/debug/lspcivvv Regards, Matthew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features
On 06/11/15 17:21, Paul Durrant wrote:
> Without some indication from an HVM domain it is not possible for a
> toolstack to know whether instantiation of a new vbd or vif should
> result in a new PV device of the appropriate type being instantiated
> in a guest. (In other words whether PV drivers are present and
> functioning).
>
> This patch document two paths which vif and vbd frontend drivers can
> use to advertise their ability to respond to new vif or vbd
> instantiations.
>
> Signed-off-by: Paul Durrant
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Keir Fraser
> Cc: Tim Deegan
> ---
> docs/misc/xenstore-paths.markdown | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/docs/misc/xenstore-paths.markdown
> b/docs/misc/xenstore-paths.markdown
> index 7701632..9e98d6f 100644
> --- a/docs/misc/xenstore-paths.markdown
> +++ b/docs/misc/xenstore-paths.markdown
> @@ -387,6 +387,18 @@ A domain writable path. Available for arbitrary domain
> use.
> A domain may write version information for PV driver $NAME using
> this path.
>
> + ~/feature/hotplug/vif = ("0"|"1") [w,HVM]
> +
> +An HVM domain can indicate to a toolstack that it is capable
> +of responding to instantiation of a new vif by bringing online a
> +new PV network device without the need for a reboot.
> +
> + ~/feature/hotplug/vbd = ("0"|"1") [w,HVM]
> +
> +An HVM domain can indicate to a toolstack that it is capable
> +of responding to instantiation of a new vbd by bringing online a
> +new PV block device without the need for a reboot.
These flags are not inherently restricted to HVM guests. Therefore, I
would avoid specifying them as such. (It is quite possible for a PV
guest not to be able to hotplug a vbd for example.)
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] docs: Document xenstore paths for domain network address information
On 06/11/15 17:21, Paul Durrant wrote: > It is useful to be able to see the network addresses in use by a domain > for a particular vif in xenstore, for example so that ssh can be invoked > by a toolstack to log into the guest domain. > > This patch documents paths to allow a domain to advertise MAC (unicast > and multicast) and IP (versions 4 and 6) address information. > > Signed-off-by: Paul Durrant > Cc: Ian Campbell > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Keir Fraser > Cc: Tim Deegan > --- > docs/misc/xenstore-paths.markdown | 29 + > 1 file changed, 29 insertions(+) > > diff --git a/docs/misc/xenstore-paths.markdown > b/docs/misc/xenstore-paths.markdown > index 9e98d6f..68d3dbf 100644 > --- a/docs/misc/xenstore-paths.markdown > +++ b/docs/misc/xenstore-paths.markdown > @@ -39,6 +39,8 @@ before regexp expansion: > * $UUID -- a UUID in the form ---- > * $NAME -- a string identifying an object within a domain. Typically >comprising only alphanumeric characters. > +* $INDEX -- an integer used as part of a path when listing a set of > +values. Typically these integers are contiguous. > > VALUES are strings and can take the following forms: > > @@ -56,6 +58,13 @@ VALUES are strings and can take the following forms: > * VERSION -- 2 or 3 integers, in decimal form separated by ".", > specifying major version, minor version, and then >(optionally) micro version. > +* MAC_ADDRESS -- 6 integers, in hexadecimal form, separated by ':', > + specifying an ethernet MAC address. > +* IPV4_ADDRESS -- 4 integers, in decimal form, separated by '.', > + specifying an IP version 4 address. > +* IPV6_ADDRESS -- 8 integers, in hexadecimal form, separated by ':', > + specifying an IP version 6 address. (There should > + be strictly 8 integers i.e. '::' compression). Given the "strictly", I presume you mean no "::" compression? But why enforce that restriction? "::" compression is unambiguous and typically makes the addresses rather more human readable. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Question about Xilinx ZynqMP
Hi, I saw Xen is supported on Xilinx ZynqMP platform at [1]. I want to have a look at the real hardware of the Xilinx ZynqMP platform and probably buy on to play with it. However, after several googling, I couldn't find anywhere to buy it. I'm wondering (a) if Xilinx has the real hardware now and Xen can run it, or (b) Xen just run on the ARM hardware emulator for Xilinx ZynqMP platform? I guess it should be (a). Am I correct? If anyone happen to have such a hardware, would you mind pointing me to someplace that I can buy it? Thank you in advance! [1] http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01219.html Best, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about Xilinx ZynqMP
On Fri, Nov 06, 2015 at 01:19:04PM -0500, Meng Xu wrote: > Hi, Hi Meng, > > I saw Xen is supported on Xilinx ZynqMP platform at [1]. > I want to have a look at the real hardware of the Xilinx ZynqMP > platform and probably buy on to play with it. > > However, after several googling, I couldn't find anywhere to buy it. > > I'm wondering > (a) if Xilinx has the real hardware now and Xen can run it, or We received first silicon about a month. I think silicon will be available to the public early next year (I think). > (b) Xen just run on the ARM hardware emulator for Xilinx ZynqMP platform? > I guess it should be (a). Am I correct? We run on various emulation environments, one of them being a custom version of QEMU. We are working on upstreaming the features to Mainline QEMU. Hope that helps! Best regards, Edgar > > If anyone happen to have such a hardware, would you mind pointing me > to someplace that I can buy it? > > Thank you in advance! > > [1] http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01219.html > > Best, > > Meng > > > > --- > Meng Xu > PhD Student in Computer and Information Science > University of Pennsylvania > http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1 1/3] x86/ept: remove unnecessary sync after resolving misconfigured entries
On 06/11/15 17:37, David Vrabel wrote: > When using EPT, type changes are done with the following steps: > > 1. Set entry as invalid (misconfigured) by settings a reserved memory > type. > > 2. Flush all EPT and combined translations (ept_sync_domain()). > > 3. Fixup misconfigured entries as required (on EPT_MISCONFIG vmexits or > when explicitly setting an entry. > > Since resolve_misconfig() only updates entries that were misconfigured, > there is no need to invalidate any translations since the hardware > does not cache misconfigured translations (vol 3, section 28.3.2). > > Remove the unnecessary (and very expensive) ept_sync_domain() calls). > > Signed-off-by: David Vrabel Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1 3/3] x86/ept: defer the invalidation until the p2m lock is released
On 06/11/15 17:37, David Vrabel wrote:
> out:
> if ( fdom )
> rcu_unlock_domain(fdom);
> return rc;
> }
> +
> +int p2m_setup(void)
> +{
> +unsigned int cpu;
> +
> +for_each_present_cpu(cpu)
> +INIT_PAGE_LIST_HEAD(&per_cpu(p2m_deferred_free_pages, cpu));
> +
> +return 0;
> +}
> +__initcall(p2m_setup);
> +
This is going to create problems for cpu hotplug, and some power
governers. The INIT_PAGE_LIST_HEAD() needs to be in a CPU_PREPARE notifier.
It might also be wise to have the DYING side confirm that the list is empty.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 63678: regressions - FAIL
flight 63678 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/63678/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-pygrub 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-amd64-pvgrub 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-i386-pvgrub 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qcow2 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-freebsd10-i386 6 xen-bootfail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-raw6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemut-rhel6hvm-amd 6 xen-bootfail REGR. vs. 60684 test-amd64-amd64-xl-credit2 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemuu-rhel6hvm-amd 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 60684 test-amd64-i386-pair 9 xen-boot/src_host fail REGR. vs. 60684 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 60684 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-vhd 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-libvirt 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-libvirt-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684 test-amd64-amd64-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 60684 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail RE
Re: [Xen-devel] Question about Xilinx ZynqMP
HI Edgar, Thank you so much for your reply! 2015-11-06 13:25 GMT-05:00 Edgar E. Iglesias : > On Fri, Nov 06, 2015 at 01:19:04PM -0500, Meng Xu wrote: > > Hi, > > Hi Meng, > > > > > I saw Xen is supported on Xilinx ZynqMP platform at [1]. > > I want to have a look at the real hardware of the Xilinx ZynqMP > > platform and probably buy on to play with it. > > > > However, after several googling, I couldn't find anywhere to buy it. > > > > I'm wondering > > (a) if Xilinx has the real hardware now and Xen can run it, or > > We received first silicon about a month. I think silicon will be available > to the public early next year (I think). > I see. Look forward to it... :-) Meng -- --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen on Arm Arndale Exynos5250
> Does your kernel have the Xen drivers (CONFIG_XEN and all which is > gated on that) enabled. In particular CONFIG_HVC_XEN. > Yes the config file I used to compile has CONFIG_XEN=y and CONFIG_HVC_XEN=y. Config file is attached. # # Automatically generated file; DO NOT EDIT. # Linux/arm 4.3.0-rc6 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_NO_IOPORT_MAP=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_PGTABLE_LEVELS=3 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_MEMCG is not set # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y # CONFIG_USERFAULTFD is not set CONFIG_MEMBARRIER=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_SYSTEM_DATA_VERIFICATION is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set # CONFIG_JUMP_LABEL is not set # CONFIG_UPROBES is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HA
[Xen-devel] [xen-4.3-testing test] 63700: regressions - FAIL
flight 63700 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/63700/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 63212 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-localmigrate fail in 63569 pass in 63700 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail pass in 63569 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail in 63569 like 63212 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 6 xen-boot fail never pass test-armhf-armhf-libvirt-qcow2 6 xen-boot fail never pass test-armhf-armhf-xl-arndale 6 xen-boot fail never pass test-armhf-armhf-libvirt 6 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 6 xen-boot fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-armhf-armhf-libvirt-raw 6 xen-boot fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 6 xen-boot fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass version targeted for testing: xen e875e0e5fcc5912f71422b53674a97e5c0ae77be baseline version: xen 85ca813ec23c5a60680e4a13777dad530065902b Last test of basis63212 2015-10-22 10:03:01 Z 15 days Failing since 63360 2015-10-29 13:39:04 Z8 days6 attempts Testing same since63381 2015-10-30 18:44:54 Z7 days5 attempts People who touched revisions under test: Andrew Cooper Ian Campbell Ian Jackson Jan Beulich jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev 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 fail test-amd64-i386-xl pass 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-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd6
[Xen-devel] [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.
All of XENVER_* have now an XSM check.
The subops for XENVER_[compile_info|changeset|commandline|
extraversion] are now priviliged operations. To not break
guests we still return an string - but it is just ''.
The rest: XENVER_[version|capabilities|
parameters|get_features|page_size|guest_handle] behave
as before - allowed by default for all guests.
This is with the XSM default policy and with the dummy ones.
Signed-off-by: Konrad Rzeszutek Wilk
---
v2: Do XSM check for all the XENVER_ ops.
v3: Add empty data conditions.
v4: Return for priv subops.
---
tools/flask/policy/policy/modules/xen/xen.te | 9 +
xen/common/kernel.c | 25 +
xen/common/version.c | 5 +
xen/include/xen/version.h| 1 +
xen/include/xsm/dummy.h | 18 ++
xen/include/xsm/xsm.h| 6 ++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c| 22 ++
xen/xsm/flask/policy/access_vectors | 4
9 files changed, 83 insertions(+), 8 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te
b/tools/flask/policy/policy/modules/xen/xen.te
index d35ae22..1ca0e65 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -73,6 +73,12 @@ allow dom0_t xen_t:xen2 {
pmu_ctrl
get_symbol
};
+
+# Allow dom0 to use XENVER_compile_info|changeset|commandline]extraversion
+allow dom0_t xen_t:xen2 {
+version_priv
+};
+
allow dom0_t xen_t:mmu memorymap;
# Allow dom0 to use these domctls on itself. For domctls acting on other
@@ -137,6 +143,9 @@ if (guest_writeconsole) {
# pmu_ctrl is for)
allow domain_type xen_t:xen2 pmu_use;
+# All all domains to use (unprivileged parts of) the XENVER_* hypercall
+allow domain_type xen_t:domain2 version_use;
+
###
#
# Domain creation
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 6a3196a..d51a3ed 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -226,9 +227,10 @@ void __init do_initcalls(void)
/*
* Simple hypercalls.
*/
-
DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
{
+bool_t deny = !!xsm_version_op(XSM_HOOK, cmd);
+
switch ( cmd )
{
case XENVER_version:
@@ -239,7 +241,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
xen_extraversion_t extraversion;
memset(extraversion, 0, sizeof(extraversion));
-safe_strcpy(extraversion, xen_extra_version());
+safe_strcpy(extraversion, deny ? xen_deny() : xen_extra_version());
if ( copy_to_guest(arg, extraversion, ARRAY_SIZE(extraversion)) )
return -EFAULT;
return 0;
@@ -250,10 +252,10 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
xen_compile_info_t info;
memset(&info, 0, sizeof(info));
-safe_strcpy(info.compiler, xen_compiler());
-safe_strcpy(info.compile_by, xen_compile_by());
-safe_strcpy(info.compile_domain, xen_compile_domain());
-safe_strcpy(info.compile_date, xen_compile_date());
+safe_strcpy(info.compiler, deny ? xen_deny() : xen_compiler());
+safe_strcpy(info.compile_by, deny ? xen_deny() : xen_compile_by());
+safe_strcpy(info.compile_domain, deny ? xen_deny() :
xen_compile_domain());
+safe_strcpy(info.compile_date, deny ? xen_deny() :
xen_compile_date());
if ( copy_to_guest(arg, &info, 1) )
return -EFAULT;
return 0;
@@ -288,7 +290,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
xen_changeset_info_t chgset;
memset(chgset, 0, sizeof(chgset));
-safe_strcpy(chgset, xen_changeset());
+safe_strcpy(chgset, deny ? xen_deny() : xen_changeset());
if ( copy_to_guest(arg, chgset, ARRAY_SIZE(chgset)) )
return -EFAULT;
return 0;
@@ -354,10 +356,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
return 0;
case XENVER_commandline:
-if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
+{
+size_t len = ARRAY_SIZE(saved_cmdline);
+
+if ( deny )
+len = strlen(xen_deny());
+
+if ( copy_to_guest(arg, deny ? xen_deny() : saved_cmdline, len) )
return -EFAULT;
return 0;
}
+}
return -ENOSYS;
}
diff --git a/xen/common/version.c b/xen/common/version.c
index b152e27..786be4e 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -55,3 +55,8 @@ const char *xen_banner(void)
{
return XEN_BANNER;
}
+
+const char *xen_deny(void)
+{
+return "";
+}
diff --git a/xen/include/xen/ver
[Xen-devel] [PATCH v2 3/3] libxl: info: Display build_id of the hypervisor.
If the hypervisor is built with we will display it.
Signed-off-by: Konrad Rzeszutek Wilk
---
v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
---
tools/libxl/libxl.c | 24
tools/libxl/libxl.h | 5 +
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c| 1 +
4 files changed, 31 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 854e957..f30f8c4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5251,6 +5251,7 @@ libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int
*nr)
const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
{
+GC_INIT(ctx);
union {
xen_extraversion_t xen_extra;
xen_compile_info_t xen_cc;
@@ -5258,8 +5259,10 @@ const libxl_version_info*
libxl_get_version_info(libxl_ctx *ctx)
xen_capabilities_info_t xen_caps;
xen_platform_parameters_t p_parms;
xen_commandline_t xen_commandline;
+xen_build_id_t build_id;
} u;
long xen_version;
+int ret;
libxl_version_info *info = &ctx->version_info;
if (info->xen_version_extra != NULL)
@@ -5292,6 +5295,27 @@ const libxl_version_info*
libxl_get_version_info(libxl_ctx *ctx)
xc_version(ctx->xch, XENVER_commandline, &u.xen_commandline);
info->commandline = strdup(u.xen_commandline);
+u.build_id.len = sizeof(u) - sizeof(u.build_id);
+ret = xc_version(ctx->xch, XENVER_build_id, &u.build_id);
+switch ( ret ) {
+case -EPERM:
+case -ENODATA:
+case 0:
+info->build_id = strdup("");
+break;
+default:
+if (ret > 0) {
+unsigned int i;
+
+info->build_id = libxl__zalloc(NOGC, (ret * 2) + 1);
+
+for (i = 0; i < ret ; i++)
+snprintf(&info->build_id[i * 2], 3, "%02hhx",
u.build_id.buf[i]);
+} else
+LOGEV(ERROR, ret, "getting build_id");
+break;
+}
+GC_FREE;
return info;
}
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 168fedd..3e2ebd1 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -212,6 +212,11 @@
#define LIBXL_HAVE_SOFT_RESET 1
/*
+ * LIBXL_HAVE_BUILD_ID means that libxl_version_info has the extra
+ * field for the hypervisor build_id.
+ */
+#define LIBXL_HAVE_BUILD_ID 1
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4d78f86..5b57824 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -353,6 +353,7 @@ libxl_version_info = Struct("version_info", [
("virt_start",uint64),
("pagesize", integer),
("commandline", string),
+("build_id", string),
], dir=DIR_OUT)
libxl_domain_create_info = Struct("domain_create_info",[
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 03442e1..287a356 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5544,6 +5544,7 @@ static void output_xeninfo(void)
printf("cc_compile_by : %s\n", info->compile_by);
printf("cc_compile_domain : %s\n", info->compile_domain);
printf("cc_compile_date: %s\n", info->compile_date);
+printf("build_id : %s\n", info->build_id);
return;
}
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] Add build-id to XENVER hypercall.
Since v1 (http://lists.xen.org/archives/html/xen-devel/2015-10/msg01090.html) - Made it work on EFI - Compiles on ARM - Redid it per comments. Attached are the three patches that will add XENVER_build_id and add the proper bits in libxl/libxc. However they also change the behavior of the existing hypercall for XENVER_[compile_info|changeset|commandline|extraversion] - that is they return the string ''. This is with XSM enabled or disabled. The new sub-ops - XENVER_build_id on the other hand will return -EPERM (XSM or not) for !priv guests. Please take a look and provide your feedback at your leisure. tools/flask/policy/policy/modules/xen/xen.te | 9 + tools/libxc/xc_private.c | 7 tools/libxc/xc_private.h | 10 ++ tools/libxl/libxl.c | 24 + tools/libxl/libxl.h | 5 +++ tools/libxl/libxl_types.idl | 1 + tools/libxl/xl_cmdimpl.c | 1 + xen/arch/x86/Makefile| 14 +--- xen/arch/x86/xen.lds.S | 6 xen/common/kernel.c | 54 +++- xen/common/version.c | 41 + xen/include/public/version.h | 15 +++- xen/include/xen/version.h| 2 ++ xen/include/xsm/dummy.h | 18 ++ xen/include/xsm/xsm.h| 6 xen/xsm/dummy.c | 1 + xen/xsm/flask/hooks.c| 22 xen/xsm/flask/policy/access_vectors | 4 +++ 18 files changed, 226 insertions(+), 14 deletions(-) Konrad Rzeszutek Wilk (2): xsm/xen_version: Add XSM for the xen_version hypercall. libxl: info: Display build_id of the hypervisor. Martin Pohlack (1): XENVER_build_id: Provide ld-embedded build-ids ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/3] XENVER_build_id: Provide ld-embedded build-ids
From: Martin Pohlack
The mechanism to get this is via the XENVER_build_id and
we add a new subsequent sub-command to retrieve the
binary build-id. The hypercall allows an arbitrary
size (the buffer and len is provided to the hypervisor).
Note that one can also retrieve the value by 'readelf -h xen-syms'.
For EFI builds we re-use the same build-id that the xen-syms
was built with.
Note that there are no changes to the XSM files (dummy.c
and hooks.c) as the priviliged subops fall in the default case.
Since the new sub-ops provides the len parameter in the
arguments to the hypercall we have to modify libxc to allow
copying the arguments before the hypercall. We provide a
new macro that modifies the bounce structure to change
the direction.
Suggested-by: Andrew Cooper
Signed-off-by: Martin Pohlack
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: Rebase it on Martin's initial patch
v2: Move it to XENVER hypercall
v3: Fix EFI building (Ross's fix)
v4: Don't use the third argument for length.
v5: Use new structure for XENVER_build_id with variable buf.
---
tools/libxc/xc_private.c| 7 +++
tools/libxc/xc_private.h| 10 ++
xen/arch/x86/Makefile | 14 +-
xen/arch/x86/xen.lds.S | 6 ++
xen/common/kernel.c | 29 +
xen/common/version.c| 36
xen/include/public/version.h| 15 ++-
xen/include/xen/version.h | 1 +
xen/xsm/flask/policy/access_vectors | 2 +-
9 files changed, 113 insertions(+), 7 deletions(-)
diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index 7c39897..9cd676e 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -712,6 +712,13 @@ int xc_version(xc_interface *xch, int cmd, void *arg)
case XENVER_commandline:
sz = sizeof(xen_commandline_t);
break;
+case XENVER_build_id:
+{
+xen_build_id_t *build_id = (xen_build_id_t *)arg;
+sz = sizeof(*build_id) + build_id->len;
+HYPERCALL_BOUNCE_SET_DIR(arg, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+break;
+}
default:
ERROR("xc_version: unknown command %d\n", cmd);
return -EINVAL;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 2df1d59..aa0cad7 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -202,6 +202,16 @@ enum {
#define DECLARE_HYPERCALL_BOUNCE(_ubuf, _sz, _dir)
DECLARE_NAMED_HYPERCALL_BOUNCE(_ubuf, _ubuf, _sz, _dir)
/*
+ * Change the direction.
+ *
+ * Can only be used if the bounce_pre/bounce_post commands have
+ * not been used.
+ */
+#define HYPERCALL_BOUNCE_SET_DIR(_buf, _dir) do { if
((HYPERCALL_BUFFER(_buf))->hbuf) \
+assert(1);
\
+
(HYPERCALL_BUFFER(_buf))->dir = _dir; \
+} while (0)
+/*
* Set the size of data to bounce. Useful when the size is not known
* when the bounce buffer is declared.
*/
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d4e507a..17a4830 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -109,15 +109,19 @@ $(TARGET)-syms: prelink.o xen.lds
$(BASEDIR)/common/symbols-dummy.o
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
| $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols --sysv --sort --warn-dup
>$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
+build_id.o: $(TARGET)-syms
+ $(OBJCOPY) --only-section=.note.gnu.build-id $< build_id.o
+
+
EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10
EFI_LDFLAGS += --image-base=$(1) --stack=0,0 --heap=0,0 --strip-debug
EFI_LDFLAGS += --section-alignment=0x20 --file-alignment=0x20
@@ -130,7 +134,7 @@ $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM)
efi/relocs-dummy.o | sed -n 's, A VIR
$(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A
ALT_START$$,,p')
# Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
$(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:)
-$(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o
$(BASEDIR)/common/symbols-dummy.o efi/mkreloc
+$(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o
$(BASEDIR)/common/symb
Re: [Xen-devel] [PATCH RFC] domain: Compile with lock_profile=y enabled.
On Thu, Nov 05, 2015 at 10:12:26AM -0700, Jan Beulich wrote:
> >>> On 02.11.15 at 18:12, wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -237,6 +237,7 @@ struct domain *alloc_domain_struct(void)
> > #ifdef CONFIG_BIGMEM
> > const unsigned int bits = 0;
> > #else
> > +int order = get_order_from_bytes(sizeof(*d));
>
> unsigned int
>
> > @@ -247,10 +248,12 @@ struct domain *alloc_domain_struct(void)
> > bits = _domain_struct_bits();
> > #endif
> >
> > -BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>
> Not unconditionally (i.e. at least non-debug builds should continue
> to have this).
The profile=y does not mandate debug=y?
Meaning if we leave this for non-debug builds with lock_profile=y
we will have an compile issue.
>
> > -d = alloc_xenheap_pages(0, MEMF_bits(bits));
> > +d = alloc_xenheap_pages(order, MEMF_bits(bits));
> > if ( d != NULL )
> > -clear_page(d);
> > +{
> > +for ( ; order >= 0; order-- )
> > +clear_page((void *)d + PAGE_SIZE*order);
>
> This loop works for orders 0 and 1, but not anything else (not
> clearing all of the pages).
Right. This below should do it:
>From 2a611285161fa94ce6a8c2708ac1c141ed6f0830 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Fri, 6 Nov 2015 16:05:20 -0500
Subject: [PATCH] domain: Compile with lock_profile=y enabled.
Our 'struct domain' has when lock profiling is enabled is bigger than
one page.
We can't use vmap nor vzalloc as both of those stash the
physical address in struct page which makes the assumptions
in 'arch_init_memory' trip over ASSERTs.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/arch/x86/domain.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index fe3be30..96a79e4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -233,6 +233,7 @@ struct domain *alloc_domain_struct(void)
#ifdef CONFIG_BIGMEM
const unsigned int bits = 0;
#else
+unsigned int order = get_order_from_bytes(sizeof(*d));
/*
* We pack the PDX of the domain structure into a 32-bit field within
* the page_info structure. Hence the MEMF_bits() restriction.
@@ -243,10 +244,18 @@ struct domain *alloc_domain_struct(void)
bits = _domain_struct_bits();
#endif
+
+#ifndef LOCK_PROFILE
BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
-d = alloc_xenheap_pages(0, MEMF_bits(bits));
+#endif
+d = alloc_xenheap_pages(order, MEMF_bits(bits));
if ( d != NULL )
-clear_page(d);
+{
+unsigned int sz;
+
+for ( sz = 0; sz < (1 << order) * PAGE_SIZE; sz += PAGE_SIZE )
+clear_page((void *)d + sz);
+}
return d;
}
--
2.1.0
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Critique of the Xen Security Process
On Fri, Nov 06, 2015, Joanna Rutkowska wrote > [snip] I was then asked to share some more > thoughts about how I thought Xen could actually improve its security > process [4]. Thanks Joanna for taking the time to put these thoughts into writing. I think there are a number of actionable things here we should be taking a look at as a community. Some of the key things from my perspective: 1. Fixing the use of the FETCHER in the build process (I know there has already been some discussion around this as part of the Raisin work). In the commercial Xen distribution I'm responsible for we actually replace this mechanism and run in an isolated build environment; I'd like to see this be the standard model. 2. "Disaggregating" the hypervisor makes a lot of sense. With Xen seeing growth in embedded and client use-cases as well as the traditional server and cloud ones it will increasingly be the case that some hypervisor features are necessary in some cases and not in others. I certainly only want my TCB to include stuff I really need. 3. Do we need to revisit entire old subsystems/features that have been subject to years of incremental development? Perhaps a line item for Xen 4.7 could be a holistic review of the PV MM code. HVMLite may help in this specific area longer term but PV (and some of our other older features) are going to be around for a while yet. 4. Development/coding guidance and standards. This is something we need anyway as we grow the community. We should consider more specific guidance on defensive coding practices. To maintainers and committers: perhaps some of these architectural direction topics would be good discussions for an in-person dev meeting. Cheers, James ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable baseline-only test] 38255: tolerable FAIL
This run is configured for baseline tests only. flight 38255 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38255/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 38238 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 38238 test-amd64-amd64-pygrub 20 guest-start/debian.repeatfail like 38238 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 38238 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail like 38238 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-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-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-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 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail 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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: xen 6f04de658574833688c3f9eab310e7834d56a9c0 baseline version: xen e294a0c3af9f4443dc692b180fb1771b1cb075e8 Last test of basis38238 2015-11-02 05:50:17 Z4 days Testing same since38255 2015-11-06 13:20:27 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Bob Liu Daniel De Graaf Dario Faggioli George Dunlap Harmandeep Kaur Ian Campbell Ian Jackson Jan Beulich Julien Grall Kevin Tian Kun Suo Olaf Hering Quan Xu Ross Lagerwall Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops
[Xen-devel] [ovmf test] 63704: all pass - PUSHED
flight 63704 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63704/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 45419de6ca5bad34567e0ca2a16a4bc78f6a6f63
baseline version:
ovmf b9ffeab7b0856db6409b53efbba51b8c336b7491
Last test of basis63599 2015-11-04 12:48:23 Z2 days
Testing same since63704 2015-11-05 19:51:22 Z1 days1 attempts
People who touched revisions under test:
Cinnamon Shia
Michael Kinney
Qin Long
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=45419de6ca5bad34567e0ca2a16a4bc78f6a6f63
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
45419de6ca5bad34567e0ca2a16a4bc78f6a6f63
+ branch=ovmf
+ revision=45419de6ca5bad34567e0ca2a16a4bc78f6a6f63
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x45419de6ca5bad34567e0ca2a16a4bc78f6a6f63 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++
[Xen-devel] [ovmf baseline-only test] 38256: all pass
This run is configured for baseline tests only. flight 38256 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38256/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 45419de6ca5bad34567e0ca2a16a4bc78f6a6f63 baseline version: ovmf b9ffeab7b0856db6409b53efbba51b8c336b7491 Last test of basis38251 2015-11-05 19:50:23 Z1 days Testing same since38256 2015-11-06 22:20:31 Z0 days1 attempts People who touched revisions under test: Cinnamon Shia Michael Kinney Qin Long jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 45419de6ca5bad34567e0ca2a16a4bc78f6a6f63 Author: Qin Long Date: Thu Nov 5 08:50:39 2015 + CryptoPkg: Add one new API (Pkcs7GetCertificatesList) for certs retrieving. Adding one new API (Pkcs7GetCertificatesList) to retrieve and sort all embedded certificates from Pkcs7 signedData. This new API will provide the support for UEFI 2.5 Secure-Boot AuditMode feature. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long Reviewed-by: Chao Zhang Reviewed-by: Ting Ye git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18729 6f19259b-4bc3-4df7-8a09-765794883524 commit a06795c6a628aa07e2274e2e3e083a5e1cc99322 Author: Cinnamon Shia Date: Thu Nov 5 01:59:24 2015 + ShellPkg/UefiDpLib: Support dumping cumulative data Add a new option -c to dump cumulative data. For example: shell> dp -c ==[ Cumulative ] (Times in microsec.) Cumulative Average ShortestLongest Name CountDurationDurationDurationDuration LoadImage: 200 1007000 0 10 StartImage:2002000 9 0 700 DB:Start:2002000 10 0 900 DB:Support: 20 10 0 07000 shell> dp -c DXE ==[ Cumulative ] (Times in microsec.) Cumulative Average ShortestLongest Name CountDurationDurationDurationDuration LoadImage: 200 1007000 0 10 StartImage:2002000 9 0 700 DB:Start:2002000 10 0 900 DB:Support: 20 10 0 07000 DXE 130003000 03000 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia Reviewed-by: Star Zeng Reviewed-by: Jaben Carsey Reviewed-by: El-Haj-Mahmoud Samer git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18728 6f19259b-4bc3-4df7-8a09-765794883524 commit 303ec9bc9f3329e2ec20ef480e071777cc5b8514 Author: Cinnamon Shia Date: Thu Nov 5 01:03:14 2015 + ShellPkg/UefiDpLib: Fix a DP cumulative data issue The value of PERF_CUM_DATA.Count and PERF_CUM_DATA.Duration field keep cumulating on every execution of dp. Initialize the CumData at dp's entry point. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia Reviewed-by: Star Zeng Reviewed-by: Jaben Carsey git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18727 6f19259b-4bc3-4df7-8a09-765794883524 commit c2e5e70a854552f91ae29e4b85dfc213dbaaca6d Author: Michael Kinney Date: Thu Nov 5 00:01:45 2015 + UefiCpuPkg: PiSmmCpuDxeSmm: Remove Framework compatibility The PiSmmCpuDxeSmm module is using PcdFrameworkCompatibilitySupport to provide compatibility with the SMM support in t
[Xen-devel] [qemu-mainline test] 63705: tolerable FAIL - PUSHED
flight 63705 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/63705/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail like 63585 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail 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-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-libvirt-vhd 9 debian-di-installfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-libvirt-raw 9 debian-di-installfail never pass version targeted for testing: qemuu496c1b19facc7b850fa0c09899fcc07a0702fbfd baseline version: qemuu79cf9fad341e6e7bd6b55395b71d5c5727d7f5b0 Last test of basis63585 2015-11-04 10:18:51 Z2 days Testing same since63705 2015-11-05 20:52:41 Z1 days1 attempts People who touched revisions under test: Denis V. Lunev Eduardo Habkost Fam Zheng Igor Mammedov Igor Skalkin John Snow Juan Quintela al3 Laszlo Ersek Liang Li Mark Cave-Ayland Markus Armbruster Michael Roth Olga Krishtal Paolo Bonzini Pavel Fedin Peter Maydell Stefan Weil jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm
[Xen-devel] [linux-3.4 test] 63703: regressions - FAIL
flight 63703 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63703/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 62277 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-xl6 xen-boot fail REGR. vs. 62277 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 62277 test-amd64-amd64-xl-xsm 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 62277 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 62277 test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 62277 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 62277 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 62277 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 62277 Tests which are failing intermittently (not blocking): test-amd64-amd64-amd64-pvgrub 3 host-install(3) broken in 63294 pass in 63703 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 63294 pass in 63703 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 63294 pass in 63703 test-amd64-i386-xl-xsm3 host-install(3) broken in 63310 pass in 63703 test-amd64-amd64-xl-qcow2 3 host-install(3) broken in 63310 pass in 63703 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 63310 pass in 63703 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 63310 pass in 63703 test-amd64-amd64-xl-credit2 3 host-install(3) broken in 63324 pass in 63703 test-amd64-i386-xl-raw3 host-install(3) broken in 63324 pass in 63703 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken in 63324 pass in 63703 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 63324 pass in 63703 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 63324 pass in 63703 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail in 63324 pass in 63703 test-amd64-amd64-xl-rtds 6 xen-bootfail pass in 63228 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 63228 test-amd64-amd64-i386-pvgrub 6 xen-bootfail pass in 63294 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail pass in 63294 test-amd64-i386-pair 10 xen-boot/dst_host fail pass in 63310 test-amd64-i386-pair 9 xen-boot/src_host fail pass in 63310 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 63310 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail pass in 63310 test-amd64-amd64-amd64-pvgrub 6 xen-boot fail pass in 63324 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 63324 test-amd64-amd64-xl-qcow2 6 xen-bootfail pass in 63338 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail pass in 63374 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail pass in 63374 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 63404 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 63404 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-libvirt-xsm 6 xen-boot fail REGR. vs. 62277 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail in 63228 blocked in 62277 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 63228 like 62277 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62277 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62277 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 62277 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail in 63228 never pass 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
